https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78795
--- Comment #7 from Markus Trippelsdorf ---
(In reply to Vincent Lefèvre from comment #6)
> Hmm... I can see the changes in the GCC 4.9 release notes. Something not
> obvious (the last time I had tested LTO was with GCC 4.8). And I would have
> e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77485
--- Comment #7 from Jeffrey A. Law ---
There was a bit of cruft and a missed ADDR_EXPR in that last fragment of gimple
code.
;; basic block 2, loop depth 0, count 0, freq 0, maybe hot
;;prev block 0, next block 1, flags: (NEW, REACHABLE, V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78786
Martin Sebor changed:
What|Removed |Added
Keywords||ice-on-valid-code, patch
--- Comment #5 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804
Bug ID: 78804
Summary: [RX] -m64bit-doubles does not work
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78793
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78795
--- Comment #6 from Vincent Lefèvre ---
Hmm... I can see the changes in the GCC 4.9 release notes. Something not
obvious (the last time I had tested LTO was with GCC 4.8). And I would have
expected libtool to select the right ar/ranlib/nm tools,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78795
--- Comment #5 from Vincent Lefèvre ---
(In reply to Markus Trippelsdorf from comment #3)
> Also make sure that nm, ar and ranlib use the liblto_plugin,
> by either using wrappers (gcc-ar, etc.) or setting up a symlink
> to the plugin in lib/bfd-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516
--- Comment #7 from Peter Bergner ---
(In reply to Joseph S. Myers from comment #6)
> With the "updated fix" gcc-pr78516.v2.diff applied I get an ICE building
> glibc. Preprocessed source attached. Compile with:
> powerpc-linux-gnuspe-gcc -S -f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72717
Michael Meissner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72717
--- Comment #8 from Michael Meissner ---
Author: meissner
Date: Tue Dec 13 23:56:17 2016
New Revision: 243626
URL: https://gcc.gnu.org/viewcvs?rev=243626&root=gcc&view=rev
Log:
[gcc]
2016-12-13 Michael Meissner
Backport from mainline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77485
--- Comment #6 from Jeffrey A. Law ---
So DSE involving CONSTRUCTOR nodes is a bit of a pain.
The way CONSTRUCTOR nodes are used past gimplification is awkward for DSE.
Specifically we have a CONSTRUCTOR node with no ELTS. The semantics of tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78779
--- Comment #3 from joseph at codesourcery dot com ---
The fallthroughs are intentional.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78768
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76731
Uroš Bizjak changed:
What|Removed |Added
CC||hjl at gcc dot gnu.org
--- Comment #7 from
'
con%str(2)='DEF'
con%str(3)='123'
write(*,*) 'dim=', size(con%str), ' len=', len(con%str(1))
write(*,*) con%str(1)
do j=1, n
write(*,*) 'CON ->', con%str(j), '<- ', len(con%str(j))
end do
end program testallo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76731
--- Comment #6 from Wenzel Jakob ---
Are there any news here? This is clearly an issue, and it would be nice to fix
it. I currently can't compile my AVX512 project on GCC due to this bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69481
Nathan Sidwell changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69481
--- Comment #12 from Nathan Sidwell ---
Author: nathan
Date: Tue Dec 13 20:43:08 2016
New Revision: 243624
URL: https://gcc.gnu.org/viewcvs?rev=243624&root=gcc&view=rev
Log:
cp/
PR c++/69481
* cp-tree.h (TYPE_TEMPLATE_INF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65618
James Cowgill changed:
What|Removed |Added
CC||james410 at cowgill dot org.uk
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170
--- Comment #12 from Jan Kratochvil ---
(In reply to Jonathan Wakely from comment #7)
> That doesn't help:
>
> std::vector::iterator it;
> {
> std::vector v{1};
> it = v.begin();
> }
>
> The iterator is safely initialized, safel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78486
--- Comment #5 from Jim Michaels ---
then add it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170
--- Comment #11 from Jan Kratochvil ---
(In reply to Jonathan Wakely from comment #9)
> Most developers don't even know the debug mode exists.
That's a problem communicating it to users. -O0 -g would be best to always use
-D_GLIBCXX_DEBUG if th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78800
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-invalid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78797
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72717
--- Comment #7 from Michael Meissner ---
Yes, it is fixed on the trunk, but I was keeping the PR open until I installed
it on the GCC 6 branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78798
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78798
--- Comment #1 from janus at gcc dot gnu.org ---
Author: janus
Date: Tue Dec 13 18:55:20 2016
New Revision: 243621
URL: https://gcc.gnu.org/viewcvs?rev=243621&root=gcc&view=rev
Log:
2016-12-13 Janus Weil
PR fortran/78798
* gfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78801
--- Comment #1 from Gerhard Steinmetz
---
With option -O0 :
$ gfortran-7-20161211 -O0 -c z1.f90
z1.f90:2:0:
character(8) :: g
internal compiler error: in convert_move, at expr.c:228
0x92d1ec convert_move(rtx_def*, rtx_def*, int)
.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78801
Bug ID: 78801
Summary: ICE in estimate_move_cost, at tree-inline.c:3845
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78800
Bug ID: 78800
Summary: ICE in compare_parameter, at fortran/interface.c:2246
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78799
Bug ID: 78799
Summary: ms_abi handles return of __int128 by value incorrectly
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77532
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-invalid-code,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78665
--- Comment #2 from Richard W.M. Jones ---
The code which calculates seg_len is surely quite interesting in that case:
size_t seg_len = block_len (h, blkoff, &used);
if (seg_len <= 4 || (seg_len & 3) != 0) {
The block_len function w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77532
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
Tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516
--- Comment #6 from Joseph S. Myers ---
Created attachment 40329
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40329&action=edit
Preprocessed source
With the "updated fix" gcc-pr78516.v2.diff applied I get an ICE building glibc.
Preproce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78796
--- Comment #6 from wilco at gcc dot gnu.org ---
(In reply to James Greenhalgh from comment #4)
> This looks sensible, but why not also drop the:
>
> if (nopcrelative_literal_loads
>
> As was done in r237607?
>
> Wilco, can you comment on why
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78796
--- Comment #5 from Jakub Jelinek ---
(In reply to James Greenhalgh from comment #4)
> This looks sensible, but why not also drop the:
>
> if (nopcrelative_literal_loads
>
> As was done in r237607?
I wanted to fix just this bug. The r237607
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78529
--- Comment #21 from amker at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #20)
> Unless you do something very nasty in the spec files (in which case you
> should just avoid those tests), the user specified objects should always
> a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78796
James Greenhalgh changed:
What|Removed |Added
CC||jgreenhalgh at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78798
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78798
Bug ID: 78798
Summary: [cleanup] some int-valued functions should be bool
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78763
--- Comment #5 from Jiri Danek ---
On Mon, Dec 12, 2016 at 3:10 PM, marxin at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78763
>
> --- Comment #4 from Martin Liška ---
> I was able to run b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78787
Domani Hannes changed:
What|Removed |Added
CC||ssbssa at yahoo dot de
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78796
--- Comment #3 from wilco at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #2)
> I can bootstrap/regtest this on aarch64-linux, but 6.3 rc1 is planned for
> tomorrow. Could the aarch64 maintainers review it before then (if they want
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78656
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70936
Rolf Eike Beer changed:
What|Removed |Added
CC||e...@sf-mail.de
--- Comment #10 from Ro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78545
--- Comment #5 from janus at gcc dot gnu.org ---
Patch at: https://gcc.gnu.org/ml/fortran/2016-11/msg00244.html
Dominique, I had already approved this patch back in November, but apparently
you have never committed it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78794
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78718
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78797
Bug ID: 78797
Summary: It is time perhaps to implement -std=f2015
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78718
Jim MacArthur changed:
What|Removed |Added
CC||jim.macarthur at codethink dot
co.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78791
--- Comment #3 from Eric Botcazou ---
> (insn 305 183 306 22 (set (mem/c:SI (plus:SI (reg/f:SI 20 frame)
> (const_int -8 [0xfff8])) [0 S4 A64])
> (subreg:SI (reg:DI 113 [ divmod_tmp_66 ]) 0)) -1
> (nil))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78794
--- Comment #10 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Dec 13 17:15:35 2016
New Revision: 243615
URL: https://gcc.gnu.org/viewcvs?rev=243615&root=gcc&view=rev
Log:
PR target/78794
* config/i386/i386.c (dimode_scal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59874
--- Comment #8 from Allan Jensen ---
Thanks that looks good. I will test it when I have a chance. I am changing the
Qt sources to not assume the presence of __builtin_clzs when __BMI__ is
defined. It can use __builtin_clz() and __builtin_ctz()-16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48361
--- Comment #13 from Luca Ingianni ---
I hope the files I just uploaded might be of use.
lcov hangs indefinitely on this file.
Command line:
/usr/bin/lcov --rc lcov_branch_coverage=1 --directory . --capture
--output-file unittests.info
This w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48361
--- Comment #12 from Luca Ingianni ---
Created attachment 40328
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40328&action=edit
the .gcda file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77785
--- Comment #7 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Tue Dec 13 16:47:48 2016
New Revision: 243614
URL: https://gcc.gnu.org/viewcvs?rev=243614&root=gcc&view=rev
Log:
gcc/fortran/ChangeLog:
2016-12-13 Andre Vehreschild
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48361
--- Comment #11 from Luca Ingianni ---
Created attachment 40327
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40327&action=edit
teh gcov file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48361
--- Comment #10 from Luca Ingianni ---
Created attachment 40326
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40326&action=edit
the soure file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78486
--- Comment #4 from Jonathan Wakely ---
That was never in in the first place, so it can't have been removed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78731
--- Comment #6 from Jeffrey A. Law ---
The patch is fine -- it can't hurt correctness and it's less invasive than
pulling out all the backedge handling like we did for later releases.
My only worry is that it's really a bandaid for code that is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78795
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78796
Jakub Jelinek changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78796
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78486
--- Comment #3 from Jim Michaels ---
also,
u16strfuncs-nostr.cpp:612:3: error: 'u16out' is not a member of 'std'
std::u16out<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78796
Bug ID: 78796
Summary: TLS fails to link on aarch64 with -mcmodel=large
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78794
--- Comment #9 from Yuri Rumyantsev ---
Hi Uros,
I checked thta with your patch performance is recovered on Avoton machine:
before after
462.libquantum18.400020.9000 +13.58%
Best regards.
Yuri.
2016-12-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78795
--- Comment #3 from Markus Trippelsdorf ---
Also make sure that nm, ar and ranlib use the liblto_plugin,
by either using wrappers (gcc-ar, etc.) or setting up a symlink
to the plugin in lib/bfd-plugins/.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78795
--- Comment #2 from Vincent Lefèvre ---
Do you mean that's a bug in GMP? Note that when I used the same options in the
past (2012), there were no problems with GCC 4.7.1 and GMP 5.0.5.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170
--- Comment #10 from Jonathan Wakely ---
(In reply to Jan Kratochvil from comment #6)
> This all depends more on a different non-pretty-printers feature I plan to
> file for libstdc++ for years but I have never done so yet. With
> -D_GLIBCXX_DEB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170
--- Comment #9 from Jonathan Wakely ---
(In reply to Jan Kratochvil from comment #8)
> (In reply to Jonathan Wakely from comment #7)
> > But most code isn't compiled with debug mode enabled.
>
> IMO all code for debugging with pretty printers is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78428
Martin Liška changed:
What|Removed |Added
Summary|[5/6/7 Regression] wrong|[5/6 Regression] wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78795
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78756
--- Comment #3 from Mojca Miklavec ---
And just for the reference, here's the commit that fixed the behaviour for us:
https://github.com/macports/macports-ports/commit/0b41554b5c627dcd5d095b1b432f554993df4c90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78756
--- Comment #2 from Mojca Miklavec ---
I just wanted to confirm that doing the same kind of replacement for gfortran
as our package manager does for gcc, I get the expected result. So gfortran's
info file doesn't seem to behave any different from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953
--- Comment #24 from Vincent Lefèvre ---
Thanks for confirming. And indeed, I also get a failure with GCC 4.9.4, so that
it is really different. For the reference, I've reported bug 78795.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78781
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78795
Bug ID: 78795
Summary: LTO causes undefined reference errors when linking
with GMP "make check"
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953
--- Comment #23 from Markus Trippelsdorf ---
(In reply to Vincent Lefèvre from comment #22)
> I get the same kind of errors with "make check" for GMP 6.1.1 by using GCC
> 6.2.1 and LTO (-flto=jobserve -fuse-linker-plugin), e.g.
>
> /tmp/ccZvS3pG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78794
--- Comment #8 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #7)
> Yes, this is a good idea.
Also, since pandn on non-BMI target replaces four arith insns with one, the
gain should be raised for 2 * ix86_cost->add for a total of 3 *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170
--- Comment #8 from Jan Kratochvil ---
(In reply to Jonathan Wakely from comment #7)
> That doesn't help:
>
> std::vector::iterator it;
> {
> std::vector v{1};
> it = v.begin();
> }
>
> The iterator is safely initialized, safely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78737
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78725
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170
--- Comment #7 from Jonathan Wakely ---
(In reply to Jan Kratochvil from comment #6)
> (In reply to Jonathan Wakely from comment #5)
> > I think it's simply wrong to automatically dereference iterators. GDB
> > doesn't do that when printing point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78794
--- Comment #7 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #6)
> Shouldn't that take into account whether there is a scalar andn or not?
> I.e. only bump the gain if !TARGET_BMI?
Yes, this is a good idea.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78737
--- Comment #25 from janus at gcc dot gnu.org ---
Author: janus
Date: Tue Dec 13 14:28:17 2016
New Revision: 243609
URL: https://gcc.gnu.org/viewcvs?rev=243609&root=gcc&view=rev
Log:
2016-12-13 Janus Weil
Paul Thomas
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78794
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77830
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170
--- Comment #6 from Jan Kratochvil ---
(In reply to Jonathan Wakely from comment #5)
> I think it's simply wrong to automatically dereference iterators. GDB
> doesn't do that when printing pointers, so why do the pretty printers do it
> for itera
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78725
--- Comment #6 from Michael Matz ---
Author: matz
Date: Tue Dec 13 14:14:41 2016
New Revision: 243606
URL: https://gcc.gnu.org/viewcvs?rev=243606&root=gcc&view=rev
Log:
Fix pr78725
PR tree-optimization/78725
* tree-ssa-loop-spli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59161
--- Comment #4 from Jonathan Wakely ---
This seems like a GDB bug, since all the pretty printer does is:
def to_string(self):
return self.val['_M_current'].dereference()
So stringifying that is done by GDB, and should produce the "r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59874
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65434
--- Comment #10 from Jonathan Wakely ---
See https://gcc.gnu.org/ml/gcc-patches/2016-12/msg01158.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170
--- Comment #5 from Jonathan Wakely ---
I think it's simply wrong to automatically dereference iterators. GDB doesn't
do that when printing pointers, so why do the pretty printers do it for
iterators?
There are loads of cases where it does the w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78794
--- Comment #5 from Uroš Bizjak ---
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 1cd1cd8..f718040 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -3417,7 +3417,10 @@ dimode_scalar_chain::compute_convert_g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59171
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
--- Comment #42 from Mark Wielaard ---
(In reply to Markus Trippelsdorf from comment #41)
> (In reply to Mark Wielaard from comment #40)
> > But I still haven't figured out why we need to allow 2 levels of recursion
> > for some of the cases. See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78794
--- Comment #4 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #3)
> Perhaps as simple as:
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 1cd1cd8..6899d4f 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/con
1 - 100 of 160 matches
Mail list logo
