http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60106
Bug ID: 60106
Summary: ICE in g++.dg/gomp/pr59150.C
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assigne
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60105
Bug ID: 60105
Summary: [C++11] g++ segfault on enable_if explicit cast
operator
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priori
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40977
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56824
--- Comment #9 from Magnus Reftel ---
Thanks for the patch! I applied it on top of
53c3c39b96df9c6a6368bf0d6acfd28a7af3cb63 and tested.
Without the patch, the error was still printed when compiling the testcase.
With the patch, the error was not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088
--- Comment #21 from Jouko Orava ---
This bug is a duplicate of #55916.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59918
--- Comment #9 from Jan Hubicka ---
Author: hubicka
Date: Fri Feb 7 06:01:36 2014
New Revision: 207592
URL: http://gcc.gnu.org/viewcvs?rev=207592&root=gcc&view=rev
Log:
PR ipa/59918
* ipa-devirt.c (record_target_from_binfo): Remove overa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60103
--- Comment #2 from Chengnian Sun ---
(In reply to Andrew Pinski from comment #1)
> I think C11 and C90/C99 have a different idea here. There is a relative
> sequence point between the function call fn2 and the 0 but there is no
> sequence point
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59918
--- Comment #8 from Jan Hubicka ---
This is just over-active sanity check
Index: ipa-devirt.c
===
--- ipa-devirt.c (revision 207588)
+++ ipa-devirt.c (working copy)
@@ -689,10 +689,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19377
--- Comment #11 from Andrey Belevantsev ---
(In reply to fabien from comment #10)
> The testcase is not valid, as a using declaration shall refer to a direct
> base class, which is not the case in 'using ns::Base::i' (the namespace ns
> does not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60035
Conrad changed:
What|Removed |Added
CC||conradsand.arma at gmail dot
com
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088
--- Comment #20 from Jouko Orava ---
Apologies, Jacob; my advice was faulty.
Could you please retest using the following?
Compile the binary using
gfortran -march=native -ggdb newtest.f90 -o newtest
then start gdb,
gdb newtest
and run unt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088
--- Comment #19 from Jacob Abel ---
jake@Jake-E1505:~/Desktop$ gfortran -static -march=native
-Wl,-uquadmath_snprintf newtest.f90 -o newtest
jake@Jake-E1505:~/Desktop$ gdb newtest
GNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu
Copyright (C) 2013 Free So
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59918
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #7 from Jan Hubicka -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #47 from Jan Hubicka ---
Author: hubicka
Date: Fri Feb 7 02:27:05 2014
New Revision: 207589
URL: http://gcc.gnu.org/viewcvs?rev=207589&root=gcc&view=rev
Log:
PR ipa/59469
* lto-cgraph.c (lto_output_node): Use
symtab_get_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088
--- Comment #18 from Jouko Orava ---
Addendum: the unaligned access causing the segfault seems to occur
because __libc_malloc returns an address aligned to 8 bytes, but
it is used as if it was aligned to 16 bytes. The disassembly is
80493a0: e8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60077
--- Comment #4 from Jan Hubicka ---
Author: hubicka
Date: Fri Feb 7 02:11:27 2014
New Revision: 207587
URL: http://gcc.gnu.org/viewcvs?rev=207587&root=gcc&view=rev
Log:
PR target/60077
* expr.c (emit_move_resolve_push): Export; be bit m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #48 from Jan Hubicka ---
Author: hubicka
Date: Fri Feb 7 02:27:37 2014
New Revision: 207590
URL: http://gcc.gnu.org/viewcvs?rev=207590&root=gcc&view=rev
Log:
PR ipa/59469
* lto-cgraph.c (lto_output_node): Use
symtab_get_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60077
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #49 from Jan Hubicka ---
Author: hubicka
Date: Fri Feb 7 02:28:33 2014
New Revision: 207591
URL: http://gcc.gnu.org/viewcvs?rev=207591&root=gcc&view=rev
Log:
PR ipa/59469
* lto-cgraph.c (lto_output_node): Use
symtab_get_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088
--- Comment #17 from Jouko Orava ---
I asked and received the details from Jacob Abel off-list, to find out if
this bug #60088 is related to bug #50201. They do not seem to be.
The instruction causing the segfault in this bug #60088 is
66 0f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60104
Bug ID: 60104
Summary: load not folded into indirect branch on x86-64
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60103
--- Comment #1 from Andrew Pinski ---
I think C11 and C90/C99 have a different idea here. There is a relative
sequence point between the function call fn2 and the 0 but there is no sequence
point between the two assignments I think.
Sequence poi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60103
Bug ID: 60103
Summary: Spurious -Wsequence-point warning with -O1
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088
--- Comment #16 from Jacob Abel ---
Still segfaults, at least on MinGW:
C:\Users\Jake\Downloads>gfortran -march=native -Wl,-uquadmath_snprintf
newtest.f
90
C:\Users\Jake\Downloads>a
Program received signal SIGSEGV: Segmentation fault - invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088
Jouko Orava changed:
What|Removed |Added
CC||jouko.orava at iki dot fi
--- Comment #15 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60032
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57951
Douglas Bagnall changed:
What|Removed |Added
CC||douglas at halo dot gen.nz
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201
--- Comment #9 from Jouko Orava ---
It turns out that while fdp2.f90,
PROGRAM fdp2
IMPLICIT none
INTEGER, PARAMETER :: b128 = SELECTED_REAL_KIND(33, 1000)
REAL(KIND=b128) :: x(4)
x = 3.4_b128
PRINT *, KI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088
--- Comment #14 from kargl at gcc dot gnu.org ---
(In reply to Jacob Abel from comment #8)
> Seriously? Look, you falsely assumed it was mingw only.
Yes, with the information I had at the time, I thought the
problem was mingw specific.
> No wonde
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088
--- Comment #13 from Jacob Abel ---
The following file:
SUBROUTINE test(N)
IMPLICIT NONE
INTEGER, INTENT(IN) :: N
REAL(KIND=16) :: array(N)
array = 0
END SUBROUTINE test
PROGRAM main
IMPLICIT NONE
CALL test(10)
END PROGRAM main
Creates the same
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088
--- Comment #12 from Jacob Abel ---
Created attachment 32074
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32074&action=edit
NEW smaller simpler file to create the segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60030
--- Comment #2 from Jakub Jelinek ---
Author: jakub
Date: Thu Feb 6 21:54:21 2014
New Revision: 207582
URL: http://gcc.gnu.org/viewcvs?rev=207582&root=gcc&view=rev
Log:
PR rtl-optimization/60030
* internal-fn.c (ubsan_expand_si_overflow_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52714
--- Comment #13 from Jeffrey A. Law ---
BTW, compiling with -O2 rather than -O1 makes this problem go away.
The problematical sequence (testing that the result of an alloca call is
nonzero) is eliminated by the VRP optimizers which only run at -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088
--- Comment #11 from Jacob Abel ---
The culprit that -march=native activates on my Core i7 laptop is -mavx.
Compiling with -mavx causes the segfault, without is fine. Unfortunately, that
flag was not set on my other laptop, so might be multiple is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102
Bug ID: 60102
Summary: powerpc fp-bit ices at dwf_regno
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52714
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
Assignee
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59632
Volker Reichelt changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201
--- Comment #8 from Jouko Orava ---
I confirm, still occurs with 4.7.3 and 4.8.1.
For simplicity, I obtained the 4.7 and 4.8 versions from Ubuntu toolchain test
builds' PPA, https://launchpad.net/~ubuntu-toolchain-r/.
GNU Fortran 4.7.3 (Ubuntu/L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46481
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60100
--- Comment #4 from lavr at ncbi dot nlm.nih.gov ---
Created attachment 32072
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32072&action=edit
Preprocessed C source that fails to produce a warning when compiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60101
Bug ID: 60101
Summary: Long compile times when mixed complex floating point
datatypes are used in lengthy expressions
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60100
--- Comment #3 from lavr at ncbi dot nlm.nih.gov ---
Ok, sorry and let me start again. My original mockup case wasn't good enough.
So attached is the real (preprocessed) code that fails to produce a warning
(yet when compiled from the .c form, th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60100
--- Comment #2 from lavr at ncbi dot nlm.nih.gov ---
> Because your command line did not actual compile anything.
Indeed. with .i I see the warning again. But I can't see
any warning if the precompiled file is processed through distcc...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088
--- Comment #10 from Dominique d'Humieres ---
This could be a duplicate of pr50201.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60100
--- Comment #1 from Andrew Pinski ---
>Also, I'm not sure why there is a bogus warning about linking here (and not
>when
compiling right from the source file, above).
Because your command line did not actual compile anything. Use the .i suffix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60100
Bug ID: 60100
Summary: warning disappears when preprocessed source is
compiled
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priorit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201
--- Comment #7 from Dominique d'Humieres ---
> Confirmed. The second test case still segfaults when run if compiled with
> -static in Linux 3.8.0 x86_64 kernel on Ubuntu 12.04.4 LTS, using
> gfortran 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5).
The 4.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60099
--- Comment #6 from David Kredba ---
Revision 207565 is fine with it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58785
Yvan Roux changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58785
--- Comment #2 from Yvan Roux ---
Yes, I fixed it at r205581 but the PR reference in the ChangeLog disappeared
between the submission and the commit :(
Yvan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201
Jouko Orava changed:
What|Removed |Added
CC||jouko.orava at iki dot fi
--- Comment #6 fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60099
--- Comment #5 from David Kredba ---
Created attachment 32069
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32069&action=edit
Original ii file gzipped
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60099
--- Comment #4 from David Kredba ---
Created attachment 32068
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32068&action=edit
testcase.i produced by c-reduce
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,
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=58785
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
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=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
--- Comment #1 from David Kredba ---
I am sorry, revision 207472.
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=59776
Marek Polacek changed:
What|Removed |Added
Priority|P2 |P1
Version|4.8.2
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=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=58699
Ramana Radhakrishnan changed:
What|Removed |Added
Keywords||missed-optimization
St
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=58784
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
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=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=59984
Jakub Jelinek changed:
What|Removed |Added
Keywords||openmp
CC|
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=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=59575
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
--- 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=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=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=60096
Feng Wang changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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=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 #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=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=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 #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=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=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=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=60087
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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=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=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
> 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=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
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=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 #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=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
1 - 100 of 154 matches
Mail list logo
