http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60090
Bug ID: 60090
Summary: For expression without ~, gcc -O1 emits "comparison of
promoted ~unsigned with unsigned"
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #45 from Jan Hubicka ---
The bug here is that lto-cgraph.c still checks DECL_COMDAT as a condition if
symbol is duplicated or partitioned. We really need to get the logic into
lto-cgraph.c and use same test at both places... Will do t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60091
Bug ID: 60091
Summary: Misleading error messages in rank-2 pointer assignment
to rank-1 target
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60090
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60086
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60090
--- Comment #2 from Marek Polacek ---
C++ folds while parsing and here for both -O0 -O we get
y.c: In function ‘int fn1(unsigned char, unsigned char)’:
y.c:3:18: warning: comparison of promoted ~unsigned with unsigned
[-Wsign-compare]
return (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60090
--- Comment #3 from Chengnian Sun ---
Thanks, Marek.
May I ask another question on the Gcc optimizations and warnings? Is there a
policy that the warnings should be independent of the optimization levels? That
is, for all optimization levels, Gc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60013
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557
--- Comment #14 from Siddhesh Poyarekar ---
I spoke to Jason last week and have now confirmed that the first fragment
indeed works correctly with 4.8. Declaring a variable threadprivate *after* it
is defined is not yet supported, but it should no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60077
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078
--- Comment #6 from Bernd Edlinger ---
Eric,
could it be that the Finalize procedure is missing some sort of spin lock?
ed@w-ed:~/gnu/gcc-build/gcc/testsuite/ada/acats/tests/c7/c761007$ cat
c761007_0.adb
-- -- -- -- -- -- -- -- -- -- -- -- --
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60086
--- Comment #2 from Marcin Krotkiewski ---
Jakub, thank you for your comments.
> GCC right now only handles __restrict on function parameters, so in this
> case the aliasing info isn't known. While the loop is versioned for
> aliasing at runtime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60090
--- Comment #4 from Marek Polacek ---
I believe we strive for the warnings be independent of the optimization level,
but it's not always possible, we have tons of bugs where -Wuninitialized
depends on the optimization level, sometimes -Warray-boun
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60086
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60089
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60086
--- Comment #4 from Richard Biener ---
As of posix_memalign the issue is not so much that of alias analysis (we could
handle it but we don't have a builtin right now) but that of alignment analysis
which doesn't implement alignment tracking of poi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092
Bug ID: 60092
Summary: posix_memalign not recognized to derive alias and
alignment info
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: alias, missed-o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #12 from Richard Biener ---
(In reply to Paulo J. Matos from comment #10)
> (In reply to Paulo J. Matos from comment #8)
> >
> > Made a mistake. With the attached test, the final gimple before expand for
> > the loop basic block is:
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60093
Bug ID: 60093
Summary: ICE on testsuite/c-c++-common/ubsan/overflow-*.c
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60089
Uroš Bizjak changed:
What|Removed |Added
CC||ubizjak at gmail dot com
--- Comment #2 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60093
Bernd Edlinger changed:
What|Removed |Added
Target||armv7l-unknown-linux-gnueab
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59150
--- Comment #7 from Sebastian Huber ---
Your patch fixed the problem on arm-rtems:
http://gcc.gnu.org/ml/gcc-testresults/2014-02/msg00303.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60077
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60094
Bug ID: 60094
Summary: gcc.target/arm/ftest-armv7em-thumb.c fails
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60094
Bernd Edlinger changed:
What|Removed |Added
Target||armv7l-unknown-linux-gnueab
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60062
--- Comment #6 from Jakub Jelinek ---
Author: jakub
Date: Thu Feb 6 10:54:20 2014
New Revision: 207549
URL: http://gcc.gnu.org/viewcvs?rev=207549&root=gcc&view=rev
Log:
PR target/60062
* tree.h (opts_for_fn): New inline function.
(op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59150
--- Comment #8 from Jakub Jelinek ---
Author: jakub
Date: Thu Feb 6 10:59:30 2014
New Revision: 207551
URL: http://gcc.gnu.org/viewcvs?rev=207551&root=gcc&view=rev
Log:
PR middle-end/59150
* tree-vect-data-refs.c (vect_analyze_data_refs)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60089
--- Comment #3 from Marc Glisse ---
(In reply to Richard Biener from comment #1)
> You'd need to disable complex lowering at the GIMPLE level and see what
> support is missing from RTL expansion for example.
>
> For the disabling I'd suggest addi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #13 from Paulo J. Matos ---
(In reply to Richard Biener from comment #12)
>
> Note that {1, +, 1}_1 is unsigned. The issue is that while i is short
> i++ is really i = (short)((int) i + 1) and thus only the operation in
> type 'int'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60094
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #14 from Paulo J. Matos ---
Something like this which looks much simpler hits the same problem:
extern int arr[];
void
foo32 (int limit)
{
short i;
for (i = 0; (int)i < limit; i++)
arr[i] += 1;
}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092
--- Comment #3 from Richard Biener ---
Created attachment 32064
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32064&action=edit
part #1, aliasing
I've implemented the aliasing parts (and the builtin obviously).
It's true that doing
posi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078
--- Comment #7 from Eric Botcazou ---
> could it be that the Finalize procedure is missing some sort of spin lock?
There are already explicit delays in the test, so very likely not.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #15 from rguenther at suse dot de ---
On Thu, 6 Feb 2014, pa...@matos-sorge.com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
>
> --- Comment #14 from Paulo J. Matos ---
> Something like this which looks much simpler hi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60094
--- Comment #3 from Bernd Edlinger ---
trunk revision 207409
Well, in this case, I'll repeat this test next week.(In reply to ktkachov from
comment #2)
> Bernd, which revision is this?
> I thought this would have been fixed with r207418
trunk re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60080
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60095
Bug ID: 60095
Summary: Dubious diagnostics for attempted surrogate call
function
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Prior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078
--- Comment #8 from Bernd Edlinger ---
(In reply to Eric Botcazou from comment #7)
> > could it be that the Finalize procedure is missing some sort of spin lock?
>
> There are already explicit delays in the test, so very likely not.
I added the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #16 from Paulo J. Matos ---
(In reply to rguent...@suse.de from comment #15)
> Exactly the same problem. C integral type promotion rules make
> that i = (short)((int)i + 1) again. Note that (int)i + 1
> does not overflow, (short) ((i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092
--- Comment #4 from Marc Glisse ---
Hack: when the return value of posix_memalign is ignored, if the platform
supports it, replace with a call to aligned_alloc (C11), which has an easier
interface.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60090
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078
--- Comment #9 from Bernd Edlinger ---
Created attachment 32065
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32065&action=edit
possible fix
well, I don't know if the Finalize method are supposed
to be called in a sequential manner, which G
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59984
--- Comment #3 from Igor Zamyatin ---
Vectorizer dump snippet for main:
foo.simdclone.0 (vect__12.7_3, vect_cst_.8_53, vect_cst_.8_53,
vect_cst_.9_51, vect_cst_.9_51);
GIMPLE_NOP
vect_v1.12_37 = MEM[(int *)vectp_v1.10_39]; (1)
v1.0_14 =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60090
--- Comment #6 from Marek Polacek ---
(In reply to Manuel López-Ibáñez from comment #5)
> http://gcc.gnu.org/ml/gcc/2013-11/msg00253.html
Exactly. I hope I can tackle at least a part of it in next stage 1.
> In those cases where folding helps t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #17 from Paulo J. Matos ---
(In reply to rguent...@suse.de from comment #15)
> On Thu, 6 Feb 2014, pa...@matos-sorge.com wrote:
>
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
> >
> > --- Comment #14 from Paulo J. Matos ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092
--- Comment #5 from Richard Biener ---
Created attachment 32066
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32066&action=edit
part #2, C11 aligned_alloc
It was noted that aligned_alloc is standard enough to be supported (and with
nicer in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092
--- Comment #6 from Jakub Jelinek ---
(In reply to Marc Glisse from comment #4)
> Hack: when the return value of posix_memalign is ignored, if the platform
> supports it, replace with a call to aligned_alloc (C11), which has an easier
> interface.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #18 from rguenther at suse dot de ---
On Thu, 6 Feb 2014, pa...@matos-sorge.com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
>
> --- Comment #17 from Paulo J. Matos ---
> (In reply to rguent...@suse.de from comment #15
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092
--- Comment #7 from Richard Biener ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to Marc Glisse from comment #4)
> > Hack: when the return value of posix_memalign is ignored, if the platform
> > supports it, replace with a call to al
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #19 from rguenther at suse dot de ---
On Thu, 6 Feb 2014, pa...@matos-sorge.com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
>
> --- Comment #16 from Paulo J. Matos ---
> (In reply to rguent...@suse.de from comment #15
> well, I don't know if the Finalize method are supposed
> to be called in a sequential manner, which GNAT does obviously not
> guarantee.
> But how about this, for a fix?
That can't be a fix, only a workaround hiding a potential issue.
Your patch is completely changing the semantic and purpose o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60032
--- Comment #4 from Alan Modra ---
Author: amodra
Date: Thu Feb 6 13:25:38 2014
New Revision: 207553
URL: http://gcc.gnu.org/viewcvs?rev=207553&root=gcc&view=rev
Log:
PR target/60032
gcc/
* config/rs6000/rs6000.c (rs6000_secondary_memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078
--- Comment #10 from charlet at adacore dot com ---
> well, I don't know if the Finalize method are supposed
> to be called in a sequential manner, which GNAT does obviously not
> guarantee.
> But how about this, for a fix?
That can't be a fix, o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60096
Bug ID: 60096
Summary: c++11 lambda reference capture mistake
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078
--- Comment #11 from Bernd Edlinger ---
(In reply to char...@adacore.com from comment #10)
> > well, I don't know if the Finalize method are supposed
> > to be called in a sequential manner, which GNAT does obviously not
> > guarantee.
> > But how
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092
--- Comment #8 from Jakub Jelinek ---
(In reply to Richard Biener from comment #7)
> According to the specification this is wrong. Note that changing errno
> is hindering optimization. For example
>
> int foo (int *p)
> {
> *p = 1;
> malloc
> What is the test supposed to do?
Looks at the top of c761007.a, you'll find answers to this question.
> could you explain, why the test fails when the delay is added to the
> unmodified test case?
Sorry, I'm not following you here, I do not know which delay you would
add where (and why).
Arno
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078
--- Comment #12 from charlet at adacore dot com ---
> What is the test supposed to do?
Looks at the top of c761007.a, you'll find answers to this question.
> could you explain, why the test fails when the delay is added to the
> unmodified test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60097
Bug ID: 60097
Summary: spurious warning about command line option
"-Wno-mismatched-tags"
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60080
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
I just tried the patch on i386-pc-solaris2.10 and the SEGVs are gone.
Thanks for the quick fix.
Rainer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60087
--- Comment #2 from Marek Polacek ---
Author: mpolacek
Date: Thu Feb 6 13:57:37 2014
New Revision: 207554
URL: http://gcc.gnu.org/viewcvs?rev=207554&root=gcc&view=rev
Log:
PR c/60087
c-family/
* c-common.c (warn_for_sign_compare): Call w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60087
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60096
--- Comment #1 from Jonathan Wakely ---
This looks invalid to me, you return a closure that holds a dangling reference
to a function parameter that has gone out of scope.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078
--- Comment #13 from Bernd Edlinger ---
(In reply to char...@adacore.com from comment #12)
> > could you explain, why the test fails when the delay is added to the
> > unmodified test case?
>
> Sorry, I'm not following you here, I do not know whi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092
--- Comment #9 from rguenther at suse dot de ---
On Thu, 6 Feb 2014, jakub at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092
>
> --- Comment #8 from Jakub Jelinek ---
> (In reply to Richard Biener from comment #7)
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092
--- Comment #10 from Jakub Jelinek ---
(In reply to rguent...@suse.de from comment #9)
> Ok, my manpage says
>
> RETURN VALUE
>aligned_alloc(), memalign(), valloc(), and pvalloc() return a
> pointer
>to the allocated memory, or
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19377
Andrey Belevantsev changed:
What|Removed |Added
CC||abel at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092
--- Comment #11 from Andreas Schwab ---
If a function is not allowed to change errno this must be explicitly
documented.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092
--- Comment #12 from Richard Biener ---
(In reply to Andreas Schwab from comment #11)
> If a function is not allowed to change errno this must be explicitly
> documented.
That means
Index: gcc/tree-ssa-alias.c
===
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60096
--- Comment #2 from Feng Wang ---
(In reply to Jonathan Wakely from comment #1)
> This looks invalid to me, you return a closure that holds a dangling
> reference to a function parameter that has gone out of scope.
Sorry, my fault. I should have
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092
--- Comment #13 from Jakub Jelinek ---
(In reply to Richard Biener from comment #12)
> (In reply to Andreas Schwab from comment #11)
> > If a function is not allowed to change errno this must be explicitly
> > documented.
>
> That means
>
> Inde
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092
--- Comment #14 from rguenther at suse dot de ---
On Thu, 6 Feb 2014, jakub at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092
>
> --- Comment #13 from Jakub Jelinek ---
> (In reply to Richard Biener from comment #12)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60096
Feng Wang changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60098
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60098
Bug ID: 60098
Summary: DSE fails to DSE errno settings
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priori
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59992
--- Comment #2 from Jakub Jelinek ---
Author: jakub
Date: Thu Feb 6 15:47:12 2014
New Revision: 207562
URL: http://gcc.gnu.org/viewcvs?rev=207562&root=gcc&view=rev
Log:
PR debug/59992
* var-tracking.c (adjust_mems): Before adding a SET
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59575
--- Comment #32 from Jakub Jelinek ---
Author: jakub
Date: Thu Feb 6 15:52:17 2014
New Revision: 207563
URL: http://gcc.gnu.org/viewcvs?rev=207563&root=gcc&view=rev
Log:
PR target/59575
* config/arm/arm.c (emit_multi_reg_push): Add dwarf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59575
--- Comment #33 from Jakub Jelinek ---
Author: jakub
Date: Thu Feb 6 15:52:36 2014
New Revision: 207564
URL: http://gcc.gnu.org/viewcvs?rev=207564&root=gcc&view=rev
Log:
PR target/59575
* config/arm/arm.c (emit_multi_reg_push): Add dwarf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59575
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59992
--- Comment #3 from Jakub Jelinek ---
The testcase has been fixed, but unfortunately --enable-checking=yes,rtl
insn-recog.c still takes about an hour to var-track.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60032
--- Comment #5 from Jakub Jelinek ---
So fixed?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59984
Jakub Jelinek changed:
What|Removed |Added
Keywords||openmp
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19377
--- Comment #10 from fabien at gcc dot gnu.org ---
(In reply to Andrey Belevantsev from comment #9)
> Another test case of the same issue (both clang and icc compile this fine):
It is not the same issue as the protected keyword is not involved. (A
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59585
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58784
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60079
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58699
Ramana Radhakrishnan changed:
What|Removed |Added
Keywords||missed-optimization
St
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60089
--- Comment #4 from joseph at codesourcery dot com ---
Is the complex multiplication instruction C99 Annex G-conforming, or could
it only be used for -fcx-limited-range?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59585
--- Comment #4 from Yuri Gribov ---
Yup, thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59776
Marek Polacek changed:
What|Removed |Added
Priority|P2 |P1
Version|4.8.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60099
Bug ID: 60099
Summary: internal compiler error: Segmentation fault
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60099
--- Comment #1 from David Kredba ---
I am sorry, revision 207472.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #46 from Jan Hubicka ---
Created attachment 32067
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32067&action=edit
Path I am testing
Hi,
this is patch I am testing. It synchronizes the logic in lto-cgraph.c and
ipa-partition.c
It
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60099
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58785
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58847
Ramana Radhakrishnan changed:
What|Removed |Added
Keywords||missed-optimization
St
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60099
--- Comment #3 from David Kredba ---
Here it shows line number too.
./testcase.i:62:1: internal compiler error
Going to attach original ii file.
In check.sh I used in addition -I and -include that I deleted from the command
before sending here,
1 - 100 of 154 matches
Mail list logo
