https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80824
Andrew Pinski changed:
What|Removed |Added
Component|c |middle-end
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80828
--- Comment #1 from Andrew Pinski ---
e
Driver Joined Separate
From binutils' ld man page:
-e entry
--entry=entry
Use entry as the explicit symbol for beginning execution of your
program, rather than the default entry po
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78503
--- Comment #3 from Bernd Edlinger ---
It is on purpose that the warning gets suppressed
when "(N) != 0" or "(N) + 0" is used, so that won't
go away.
But may I suggest the following for the XALLOCAVEC macro:
#define XALLOCAVEC(T, N) ((N) > 0 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80610
--- Comment #13 from Steve Kargl ---
On Sat, May 20, 2017 at 04:59:10AM +, jvdelisle at gcc dot gnu.org wrote:
>
> Yes that will take some frontend magic and we have so few people to support
> gfortran (for free remember) that we may not be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80610
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80833
--- Comment #4 from Peter Cordes ---
I don't think it's worth anyone's time to implement this in 2017, but using MMX
regs for 64-bit store/load would be faster on really old CPUs that split 128b
vectors insns into two halves, like K8 and Pentium
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80833
--- Comment #3 from Peter Cordes ---
Atom's movd xmm->int is slower (lat=4, rtput=2) than its movd int->xmm (lat=3,
rtput=1), which is opposite of every other CPU (except Silvermont where they're
the same throughput but xmm->int is 1c slower). S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80833
--- Comment #2 from Peter Cordes ---
On most CPUs, psrldq / movd is optimal for xmm[1] -> int without SSE4. On
SnB-family, movd runs on port0, and psrldq can run on port5, so they can
execute in parallel. (And the second movd can run the next c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80834
Michael Meissner changed:
What|Removed |Added
Status|RESOLVED|NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80834
Michael Meissner changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80834
Bug ID: 80834
Summary: PowerPC gcc -mcpu=power9 seems to turn off
vectorization that -mcpu=power8 enables
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80820
--- Comment #3 from Peter Cordes ---
Also, going the other direction is not symmetric. On some CPUs, a store/reload
strategy for xmm->int might be better even if an ALU strategy for int->xmm is
best.
Also, the choice can depend on chunk size, s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80820
--- Comment #2 from Peter Cordes ---
See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80833.
gcc -m32 does an even worse job of getting int64_t into an xmm reg, e.g. as
part of a 64-bit atomic store.
We get a store-forwarding failure from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80833
--- Comment #1 from Peter Cordes ---
See https://godbolt.org/g/krXH9M for the functions I was looking at.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80833
Bug ID: 80833
Summary: 32-bit x86 causes store-forwarding stalls for int64_t
-> xmm
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80610
--- Comment #11 from Andrew Pinski ---
Basically to initialize all of the values of a static array, the array is
stored in gfortan memory. To do a 1GB array, you need at least 32times that
amount of virtual memory available. Related to bug 5667
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80610
--- Comment #10 from Steve Kargl ---
On Fri, May 19, 2017 at 08:31:00PM +, gustavo.hime at mpimet dot mpg.de
wrote:
>
> Are there any maintainers on the gfortran project who can see this? I am going
> to reopen the bug once more, but then I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80610
--- Comment #9 from Andrew Pinski ---
See https://www.kernel.org/doc/Documentation/vm/overcommit-accounting for more
on what is going on here. This is not under the gfortran control.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80610
--- Comment #8 from Gustavo Hime ---
>
> I understand the issue. It isn't a problem with gfortran.
>
You do not understand the issue, which I made quite clear when reporting the
bug. The code compiles, links and runs if no non-zero option is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80610
Andrew Pinski changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80806
--- Comment #5 from prathamesh3492 at gcc dot gnu.org ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01493.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80610
--- Comment #6 from Steve Kargl ---
On Fri, May 19, 2017 at 08:07:17PM +, pinskia at gcc dot gnu.org wrote:
> Status|RESOLVED|REOPENED
> Resolution|INVALID |---
>
> --- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80610
Andrew Pinski changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80610
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80610
Gustavo Hime changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79549
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80610
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70167
Jason Merrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80178
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80832
Bug ID: 80832
Summary: GCC_COLORS
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80799
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70118
Bug 70118 depends on bug 80799, which changed state.
Bug 80799 Summary: [7/8 Regression] x86-32 bits generates MMX without EMMS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80799
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80799
--- Comment #9 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri May 19 18:08:19 2017
New Revision: 248297
URL: https://gcc.gnu.org/viewcvs?rev=248297&root=gcc&view=rev
Log:
Backport from mainline
2017-05-18 Uros Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80831
Bug ID: 80831
Summary: internal compiler error: Segmentation fault with
-fsyntax-only
Product: gcc
Version: 7.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80829
--- Comment #1 from Benjamin Bannier ---
We believe this code is legal C++11 (AFAICT no explicit restrictions on
implicit conversions of `constexpr` vars), and was compiling successfully with
e.g., 6.3, so we strongly suspect a GCC regression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80830
--- Comment #1 from David Binderman ---
Reduced code, although it doesn't look like legal C++ to me:
class a;
template < b > void operator<<(a , ;
class {friend operator<<(a , ;
template < int = 3 > class c {
friend o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80333
--- Comment #4 from Jerry DeLisle ---
This is now fixed on trunk. The patch fixes both READ and WRITE traversal of
arrays of class objects using User Defined Derived Type I/O in NAMELISTs. This
could be a slick feature for "serializing" CLASS obj
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80799
--- Comment #8 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri May 19 15:51:10 2017
New Revision: 248294
URL: https://gcc.gnu.org/viewcvs?rev=248294&root=gcc&view=rev
Log:
Backport from mainline
2017-05-18 Uros Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80333
--- Comment #3 from Jerry DeLisle ---
Author: jvdelisle
Date: Fri May 19 15:48:35 2017
New Revision: 248293
URL: https://gcc.gnu.org/viewcvs?rev=248293&root=gcc&view=rev
Log:
2017-05-19 Paul Thomas
PR fortran/80333
* trans-io
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58299
--- Comment #4 from Eric Botcazou ---
> Huh? So you can blatantly ignore it there too? Not only is that completely
> asinine, it contradicts the hint on the "add attachment" link: "proposed
> *patch*, testcase, etc." Surely, it is much more lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78503
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79842
--- Comment #2 from Paul Thomas ---
(In reply to Dominique d'Humieres from comment #1)
> Do you agree with the change in comment 0? If yes, I can do the testing and
> packaging.
Yes, that's fine by me.
Thanks
Paul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80800
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80800
--- Comment #7 from Marek Polacek ---
Author: mpolacek
Date: Fri May 19 15:30:54 2017
New Revision: 248291
URL: https://gcc.gnu.org/viewcvs?rev=248291&root=gcc&view=rev
Log:
PR sanitizer/80800
* fold-const.c (extract_muldiv_1) :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80806
--- Comment #4 from Martin Sebor ---
Right, const could be used in lieu of an "in" attribute for warnings. It can't
be used for the same thing for optimization because constness can be cast away.
Bug 10138 has a good discussion on the subject.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80754
--- Comment #4 from Vladimir Makarov ---
(In reply to Wilco from comment #3)
> Patch here https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01364.html
Thanks for working on the problem, Wilco.
I'll review the patch and give you an answer on Wednesd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80830
Bug ID: 80830
Summary: ice in tsubst_copy, at cp/pt.c:14569
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80793
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60083
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80829
Bug ID: 80829
Summary: Use of constexpr constructors with base type
instantiation fails compilation
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80815
--- Comment #4 from amker at gcc dot gnu.org ---
Also the three cases:
/* If the left segment does not extend beyond the start of the
right segment the new segment length is that of the right
plus the segment di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72863
--- Comment #10 from Bill Schmidt ---
Author: wschmidt
Date: Fri May 19 14:30:02 2017
New Revision: 248287
URL: https://gcc.gnu.org/viewcvs?rev=248287&root=gcc&view=rev
Log:
2017-05-19 Bill Schmidt
Backport from mainline
2016
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79842
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79840
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58299
--- Comment #3 from Keith Marshall ---
(In reply to Eric Botcazou from comment #1)
> Patches should be posted on the gcc-patches mailing-list.
Huh? So you can blatantly ignore it there too? Not only is that completely
asinine, it contradicts t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60083
--- Comment #3 from Marek Polacek ---
Started with r139049.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80799
--- Comment #7 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri May 19 14:09:45 2017
New Revision: 248284
URL: https://gcc.gnu.org/viewcvs?rev=248284&root=gcc&view=rev
Log:
Backport from mainline
2017-05-18 Uros Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54720
--- Comment #3 from Keith Marshall ---
And, more than 4 years later, this issue persists in GCC-6.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79840
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|NEW
--- Comment #5 from David Malcolm -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79852
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79852
--- Comment #4 from David Malcolm ---
Author: dmalcolm
Date: Fri May 19 13:52:14 2017
New Revision: 248283
URL: https://gcc.gnu.org/viewcvs?rev=248283&root=gcc&view=rev
Log:
fortran: remove trailing exclamation mark from various diagnostics (PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79840
--- Comment #4 from Dominique d'Humieres ---
> Context is:
>
> gfc_fatal_error ("Can't USE the same %smodule we're building!",
> p->state == COMP_SUBMODULE ? "sub" : "");
>
> Possible i18n issue here; are "module" / "su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79840
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80610
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80826
--- Comment #8 from Jonathan Wakely ---
Even the unchanged code is almost acceptable with -fno-var-tracking-assignments
TOTAL : 357.361.11 359.181206964 kB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80826
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80826
--- Comment #6 from Jonathan Wakely ---
Using -fno-var-tracking-assignments helps too.
Inserting the right type:
TOTAL: 291.541.14 293.251237034 kB
Range-insert from an array of the right type:
TOTAL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991
Ladislav Láska changed:
What|Removed |Added
CC||krakonos at krakonos dot org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80826
--- Comment #5 from Jonathan Wakely ---
FWIW using -O1 -g -ftime-report on the original code with GCC 5.4.1 gives:
TOTAL :1387.175.14 1462.362427702 kB
And also prints the -fvar-tracking-assignments note.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80593
Richard Biener changed:
What|Removed |Added
Known to work||8.0
Summary|[7/8 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80593
--- Comment #7 from Richard Biener ---
Author: rguenth
Date: Fri May 19 12:34:54 2017
New Revision: 248269
URL: https://gcc.gnu.org/viewcvs?rev=248269&root=gcc&view=rev
Log:
2017-05-19 Richard Biener
PR c++/80593
* c-warn.c (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80826
--- Comment #4 from Jonathan Wakely ---
I don't know why it's so slow, or if it's possible to change the libstdc++ code
to help the c++98 case (I doubt it).
But it helps a lot if you insert the correct type:
mMap.insert (std::pair("1", 1));
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80593
Richard Biener changed:
What|Removed |Added
CC||s-beyer at gmx dot net
--- Comment #6 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80796
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80827
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80796
--- Comment #5 from Jonathan Wakely ---
Author: redi
Date: Fri May 19 12:28:28 2017
New Revision: 248267
URL: https://gcc.gnu.org/viewcvs?rev=248267&root=gcc&view=rev
Log:
PR libstdc++/80796 Add new std::search overload for C++17
PR lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80823
Peter Bergner changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80796
--- Comment #4 from Jonathan Wakely ---
Author: redi
Date: Fri May 19 12:11:31 2017
New Revision: 248266
URL: https://gcc.gnu.org/viewcvs?rev=248266&root=gcc&view=rev
Log:
PR libstdc++/80796 Add new std::search overload for C++17
PR lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80796
--- Comment #3 from d25fe0be@ ---
Oh, my bad.
I did't know about p0433r2, but at least I should have checked n4659
(make_xxx_searcher has already been removed there) before submitting.
My apologize. And thanks for pointing out this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80828
Bug ID: 80828
Summary: Command line option -e not documented
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80827
Bug ID: 80827
Summary: False strict-aliasing warning with certain settings
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80796
Jonathan Wakely changed:
What|Removed |Added
Status|RESOLVED|NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80796
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80821
--- Comment #4 from Richard Biener ---
Author: rguenth
Date: Fri May 19 11:13:48 2017
New Revision: 248264
URL: https://gcc.gnu.org/viewcvs?rev=248264&root=gcc&view=rev
Log:
2017-05-19 Richard Biener
PR build/80821
* genmatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80821
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64095
Jonathan Wakely changed:
What|Removed |Added
CC||gufideg at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80795
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80815
--- Comment #3 from amker at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #2)
> On Fri, 19 May 2017, amker at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80815
> >
> > --- Comment #1 from amker at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80826
--- Comment #3 from Richard Biener ---
For GCC 7 most time is spent in inlining. I suspect C++14 helps with constexpr
evaluation doing some of the stuff in the frontend.
integration : 21.73 (39%) usr 0.33 (23%) sys 22.02 (39%)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80815
--- Comment #2 from rguenther at suse dot de ---
On Fri, 19 May 2017, amker at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80815
>
> --- Comment #1 from amker at gcc dot gnu.org ---
> GCC uses vect_factor as minimal se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80826
Richard Biener changed:
What|Removed |Added
Target|Red Hat 7 Linux x86 64bit |
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80826
--- Comment #1 from seanthesheep1 at hotmail dot com ---
I had to stop the compilation as it was close to consuming 100% of the memory
and making the box unusable:
Cpu(s): 0.0%us, 6.3%sy, 0.0%ni, 88.0%id, 5.8%wa, 0.0%hi, 0.0%si,
0.0%st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80821
--- Comment #2 from Richard Biener ---
Index: gcc/genmatch.c
===
--- gcc/genmatch.c (revision 248263)
+++ gcc/genmatch.c (working copy)
@@ -3005,6 +3013,8 @@ dt_node::gen_k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80815
--- Comment #1 from amker at gcc dot gnu.org ---
GCC uses vect_factor as minimal segment length for dr_b when merging alias
pairs, I think it could be relaxed to vect_factor * abs (DR_STEP (dr_b)).
Below test shows this change can merge additiona
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80826
Bug ID: 80826
Summary: Compilation Time for many of std::map insertions
Product: gcc
Version: 4.8.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80806
--- Comment #3 from Daniel Fruzynski ---
"in" attribute is similar to "const", I am not sure if we need another one for
this.
"out" attribute would be handy. I recall than in the past I was looking for it.
gcc can print warning that uninitialize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78503
jbeulich at novell dot com changed:
What|Removed |Added
CC||jbeulich at novell dot com
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
Daniel,
> Would you be so kind as to test this on Solaris for me please? I don't have
> access to a Solaris machine and I've never set it up before, so I wouldn't
> even
> know where t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78962
Daniel Santos changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80819
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
1 - 100 of 108 matches
Mail list logo
