https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63908
leimaohui changed:
What|Removed |Added
Target||e500v2
--- Comment #7 from leimaohui ---
(I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63908
--- Comment #6 from leimaohui ---
Created attachment 34294
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34294&action=edit
the patch backport to gcc 4.9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64336
Bug ID: 64336
Summary: Template functions are not instrumented at -O0 and -Og
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54687
--- Comment #10 from Tobias Burnus ---
Author: burnus
Date: Wed Dec 17 06:29:30 2014
New Revision: 218808
URL: https://gcc.gnu.org/viewcvs?rev=218808&root=gcc&view=rev
Log:
2014-12-17 Tobias Burnus
PR fortran/54687
gcc/
* fla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64110
--- Comment #10 from H.J. Lu ---
It fails with -m32:
[hjl@gnu-6 gcc]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/pr64110.c
-fno-diag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64331
--- Comment #4 from Senthil Kumar Selvaraj ---
Yes, running df_notes_add_problem and df_analyze in the target code does work.
Is it just REG_USED/REG_DEAD notes, or is register liveliness
(df_regs_ever_live_p etc..) also not guaranteed to be up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64335
--- Comment #1 from Ville Voutilainen ---
Pardon that, the latter example contains remnants of other experiments. Here's
a simplified version, (not that it really should matter :) )
class foo {
class bar {};
};
int main()
{
decltype (fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64335
Bug ID: 64335
Summary: decltype and access of a private member type
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52933
--- Comment #5 from Oleg Endo ---
Some of the original test cases are still not working. In particular cases
where bit positions != 31 are compared/xor'ed:
bool cmp_signs_24 (int a, int b)
{
return (a & 0x8000) ^ (b & 0x8000);
}
bool cmp_sig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64306
--- Comment #1 from Oleg Endo ---
If the alignment/offset of an unaligned 32 bit store is known to be 16 bit, it
can be done with something like:
mov r5,r0
mov.w r0,@({0|2},r4)
shlr16 r0
mov.w r0,@({2|0},r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259
--- Comment #11 from Oleg Endo ---
(In reply to thopre01 from comment #10)
>
> I have the same gimple and for me the bswap is correctly detected. Can you
> break at find_bswap_or_nop just after calling find_bswap_or_nop_1 on the if
> (!source_st
/libsystem_c.dylib
#3 0x6fb0 in __gfortrani_sys_abort () at
../../../../gcc-5-20141216/libgfortran/runtime/error.c:180
#4 0x000bcfc8 in _gfortran_abort () at
../../../../gcc-5-20141216/libgfortran/intrinsics/abort.c:33
#5 0x1a90 in ?? ()
Backtrace stopped: previous frame inner to this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47764
--- Comment #6 from Carrot ---
Another example for ppc.
Following code is disassembled from sha1dgst.o in openssl which is compiled by
gcc
:
...
80: 82 5a 52 3f addis r26,r18,23170
84: 78 9a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61265
Chris Manghane changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244
--- Comment #14 from Ondřej Čertík ---
On Tue, Dec 16, 2014 at 4:24 PM, Ondřej Čertík wrote:
> On Tue, Dec 16, 2014 at 1:46 PM, janus at gcc dot gnu.org
> wrote:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244
>>
>> --- Comment #12 from j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58650
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58650
--- Comment #1 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Tue Dec 16 23:28:31 2014
New Revision: 218801
URL: https://gcc.gnu.org/viewcvs?rev=218801&root=gcc&view=rev
Log:
/cp
2014-12-16 Paolo Carlini
PR c++/58650
* parser.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244
--- Comment #13 from Ondřej Čertík ---
On Tue, Dec 16, 2014 at 1:46 PM, janus at gcc dot gnu.org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244
>
> --- Comment #12 from janus at gcc dot gnu.org ---
> (In reply to Ondřej Čertík from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64334
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64308
--- Comment #3 from Tavian Barnes ---
@Richard Biener: Yes the range for _16 could be [0, 4294967294]. Why can't VRP
can't assume division by zero doesn't occur? If it can then it could say
anything mod [a, b] fits in [0, b - 1].
That's a reas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64334
Bug ID: 64334
Summary: Common .opt handling: Support flags which take a list
of values (-fopt=a,b,c ...)
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54687
--- Comment #9 from Manuel López-Ibáñez ---
(In reply to Tobias Burnus from comment #8)
> I concur. I think it also would be useful to support combined options like
> Fortran's -ffpe-trap= and -fcheck= or common's -fsanitize=.
Total agreement!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54687
--- Comment #8 from Tobias Burnus ---
(In reply to Manuel López-Ibáñez from comment #5)
> > Is there still something missing?
> Note that the options machinery has ways to encode String->Enum options, so
> things like gfc_handle_coarray_option an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #32 from Oleg Endo ---
Author: olegendo
Date: Tue Dec 16 21:37:42 2014
New Revision: 218795
URL: https://gcc.gnu.org/viewcvs?rev=218795&root=gcc&view=rev
Log:
gcc/testsuite/
PR target/54089
* gcc.target/sh/pr54089-1.c: Change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61246
--- Comment #3 from ian at gcc dot gnu.org ---
Author: ian
Date: Tue Dec 16 21:36:53 2014
New Revision: 218794
URL: https://gcc.gnu.org/viewcvs?rev=218794&root=gcc&view=rev
Log:
PR go/61246
compiler: Switch expression comparisons should be b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
--- Comment #46 from Oleg Endo ---
Author: olegendo
Date: Tue Dec 16 21:28:59 2014
New Revision: 218793
URL: https://gcc.gnu.org/viewcvs?rev=218793&root=gcc&view=rev
Log:
gcc/testsuite/
PR target/53513
* gcc.target/sh/fpchg.c: Rename to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63568
--- Comment #8 from Marek Polacek ---
(In reply to Oleg Endo from comment #7)
> If you decide not to do the transform at the tree level, please change this
> to a target PR and assign it to me.
I have a patch that does the transformation on matc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244
--- Comment #12 from janus at gcc dot gnu.org ---
(In reply to Ondřej Čertík from comment #11)
> So my system (RHEL6) libstdc++ library might be incompatible with the
> trunk, but I don't see why gcc couldn't compile. Any ideas how to fix
> this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54687
--- Comment #7 from Tobias Burnus ---
Author: burnus
Date: Tue Dec 16 20:44:45 2014
New Revision: 218792
URL: https://gcc.gnu.org/viewcvs?rev=218792&root=gcc&view=rev
Log:
2014-12-16 Tobias Burnus
PR fortran/54687
* gfortran.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64333
Bug ID: 64333
Summary: C++14 constexpr gives wrong results when a looping
constexpr function is evaluated twice
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Ke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63568
--- Comment #7 from Oleg Endo ---
If you decide not to do the transform at the tree level, please change this to
a target PR and assign it to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64320
--- Comment #1 from Rich Townsend ---
OK, it seems that this bug comes from building with srcdir == objdir. If I
build in a separate directory, then the problem goes away.
As an aside, I hadn't realized that using srcdir == objdir is generally
d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64328
--- Comment #3 from Tejas Belagod ---
(In reply to Jan Hubicka from comment #2)
> Indeed, the testcase is meant to be nopic. I will check how to test for
> that in dg.
>
> Honza
{ dg-require-effective-target nonpic } ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54687
--- Comment #6 from Tobias Burnus ---
Missed the PR number for the commit r218790:
2014-12-16 Tobias Burnus
PR fortran/54687
* lang.opt (fsecond-underscore, frecord-marker=8, frecord-marker=4,
frealloc-lhs, freal-8-re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296
--- Comment #15 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #13)
> Read the sources? It really depends on many factors.
There are
int max_align_compat
= optimize_size ? BITS_PER_WORD : MIN (256, MAX_OFILE_ALIGNMENT);
With -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61264
--- Comment #2 from ian at gcc dot gnu.org ---
Author: ian
Date: Tue Dec 16 19:14:54 2014
New Revision: 218789
URL: https://gcc.gnu.org/viewcvs?rev=218789&root=gcc&view=rev
Log:
PR go/61264
compiler: Fix copying behavior for empty composite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64328
--- Comment #2 from Jan Hubicka ---
Indeed, the testcase is meant to be nopic. I will check how to test for that
in dg.
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61273
--- Comment #1 from ian at gcc dot gnu.org ---
Author: ian
Date: Tue Dec 16 18:53:46 2014
New Revision: 218788
URL: https://gcc.gnu.org/viewcvs?rev=218788&root=gcc&view=rev
Log:
PR go/61273
compiler: Send statements should contextually permi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64309
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64313
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61264
Chris Manghane changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64309
--- Comment #14 from Marek Polacek ---
Author: mpolacek
Date: Tue Dec 16 18:29:01 2014
New Revision: 218787
URL: https://gcc.gnu.org/viewcvs?rev=218787&root=gcc&view=rev
Log:
PR middle-end/64309
* match.pd: Add ((1 << A) & 1) != 0 -> A =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64330
--- Comment #5 from Jakub Jelinek ---
(In reply to Kostya Serebryany from comment #4)
> So, maybe the ODR checker in the current form is not that useless.
> Sorry, couldn't resist :)
But it isn't really an ODR checker. Here it complains if two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64330
--- Comment #4 from Kostya Serebryany ---
So, maybe the ODR checker in the current form is not that useless.
Sorry, couldn't resist :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61316
Chris Manghane changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61322
Chris Manghane changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63851
--- Comment #6 from Dominique d'Humieres ---
> Yes, IPA ICF should respect 'restrict' attribute.
> May I ask you to rerun test suite with applied:
My machine is busy regtesting 4.8.4, but a quick test shows that your patch
indeed fixes this PR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332
--- Comment #6 from Manuel López-Ibáñez ---
(In reply to Azat from comment #5)
> > Whether the correct behavior is that the system_header applies to the
> > definition or to the expansion location, I am not sure. However, the bad
> > location of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64313
--- Comment #3 from joseph at codesourcery dot com ---
In the case of expf, if it's used or known to be available in a linked
library then it can be assumed to have the required semantics (since it's
reserved by ISO C90). If it's used it can a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61280
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61591
--- Comment #10 from Martin Jambor ---
Honza, given what you wrote in
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01033.html
do you want to take over this bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63851
--- Comment #5 from Martin Liška ---
Yes, IPA ICF should respect 'restrict' attribute.
May I ask you to rerun test suite with applied:
diff --git a/gcc/ipa-icf-gimple.c b/gcc/ipa-icf-gimple.c
index ec0290a..98f38ee 100644
--- a/gcc/ipa-icf-gimpl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244
--- Comment #11 from Ondřej Čertík ---
On Tue, Dec 16, 2014 at 9:47 AM, janus at gcc dot gnu.org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244
>
> --- Comment #10 from janus at gcc dot gnu.org ---
> (In reply to Ondřej Čertík from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332
--- Comment #5 from Azat ---
On Tue, Dec 16, 2014 at 05:16:41PM +, manu at gcc dot gnu.org wrote:
> The C FE does not point to __constructor (3:1 vs 3:19), thus it doesn't
> realize
> this comes from a macro expansion, thus (in your testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332
--- Comment #3 from Azat ---
On Tue, Dec 16, 2014 at 07:50:48PM +0300, Azat Khuzhin wrote:
> > --- Comment #1 from Andrew Pinski ---
> > I don't think it is system header which is being handled differently,
> > rather I
> > think it is warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62152
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61189
--- Comment #4 from Kai Tietz ---
*** Bug 62152 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332
--- Comment #2 from Azat ---
On Tue, Dec 16, 2014 at 04:46:28PM +, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332
>
> --- Comment #1 from Andrew Pinski ---
> I don't think it is system header which is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61189
--- Comment #3 from lh_mouse ---
Thanks Kai. It seems to be exactly the same reason that causes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62152. Maybe we should merge them?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244
--- Comment #10 from janus at gcc dot gnu.org ---
(In reply to Ondřej Čertík from comment #9)
> Janus, thanks a lot for fixing this!
You're welcome!
> Yes, it's part of a large code base. I'll try the trunk soon.
That would be great. Since thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332
--- Comment #1 from Andrew Pinski ---
I don't think it is system header which is being handled differently, rather I
think it is warning for attribute is being handled differently.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244
--- Comment #9 from Ondřej Čertík ---
Janus, thanks a lot for fixing this! Yes, it's part of a large code base. I'll
try the trunk soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61189
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64331
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64321
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64286
--- Comment #1 from Igor Zamyatin ---
Perhaps something like below to restrict ree for such cases?
diff --git a/gcc/ree.c b/gcc/ree.c
index 3376901..92370ea 100644
--- a/gcc/ree.c
+++ b/gcc/ree.c
@@ -1004,6 +1004,11 @@ add_removable_extension (c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332
Bug ID: 64332
Summary: gcc/g++ handles system_header differently
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
.file"a.c"
.globlx
.data
.align 64
.typex, @object
.sizex, 128
x:
.byte1
.zero127
.ident"GCC: (GNU) 5.0.0 20141216 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 pr61296]$
Which older
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64321
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63473
janus at gcc dot gnu.org changed:
What|Removed |Added
Summary|[4.9/5 Regression] Memory |Memory leak with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64319
--- Comment #2 from Brian Grayson ---
alignd() in m88ksim from SPECint95 is a poster child for this kind of
optimization -- it receives several pointers to portions of FP representations,
and then operates on them via code like this:
...
*amantl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63473
--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to janus from comment #3)
> The second message (680 bytes) occurs only with 4.9 upwards (and already in
> the first loop execution).
Actually I think this is not a real regression, but ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63473
--- Comment #3 from janus at gcc dot gnu.org ---
Here is a slightly compactified test case:
program testprogram
implicit none
type :: mytype_type
integer, allocatable :: i(:)
end type
integer :: n
type(mytype_type), allocatable ::
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64240
--- Comment #6 from fyang at gcc dot gnu.org ---
Author: fyang
Date: Tue Dec 16 14:58:03 2014
New Revision: 218780
URL: https://gcc.gnu.org/viewcvs?rev=218780&root=gcc&view=rev
Log:
+ PR rtl-optimization/64240
+ * ddg.c (mark_mem_use)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64278
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64278
--- Comment #2 from Martin Liška ---
Author: marxin
Date: Tue Dec 16 14:55:29 2014
New Revision: 218779
URL: https://gcc.gnu.org/viewcvs?rev=218779&root=gcc&view=rev
Log:
Fix for PR ipa/64278
* sreal.c (sreal::operator*): Replace std::abs w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63473
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64328
Richard Biener changed:
What|Removed |Added
Component|tree-optimization |testsuite
--- Comment #1 from Richard B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64291
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*, i?86-*-*
Priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64331
Richard Biener changed:
What|Removed |Added
Target||avr
Component|rtl-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63568
--- Comment #6 from rguenther at suse dot de ---
On Tue, 16 Dec 2014, mpolacek at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63568
>
> --- Comment #5 from Marek Polacek ---
> True. E.g. on my x86_64 i7 Nehalem I see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63568
--- Comment #5 from Marek Polacek ---
True. E.g. on my x86_64 i7 Nehalem I see (using ./cc1 -quiet -O2 qq.c -mbmi)
andn%edi, %edx, %edi
andl%edx, %esi
movl%edi, %eax
orl %esi, %eax
ret
f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64330
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296
--- Comment #13 from Jakub Jelinek ---
Read the sources? It really depends on many factors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296
--- Comment #12 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #11)
> If you hit the assumption beyond what ABI mandates on some public symbol
> issue in some older GCC version, then sure, if you have that public symbol
> defined by ICC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63568
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296
--- Comment #11 from Jakub Jelinek ---
If you hit the assumption beyond what ABI mandates on some public symbol issue
in some older GCC version, then sure, if you have that public symbol defined by
ICC, it will misbehave. But, if it is compiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63568
--- Comment #3 from Marek Polacek ---
FWIW, I used this to check the whether the transformation is correct:
int
main ()
{
for (int i = -1000; i < 1000; ++i)
for (int a = -1000; a < 1000; ++a)
for (int b = -1000; b < 1000; ++b)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64330
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296
--- Comment #10 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #9)
> (In reply to H.J. Lu from comment #8)
> > Do you have a testcase to show decreasing DATA_ALIGNMENT would break
> > backwards compatibility with older gcc versions?
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296
--- Comment #9 from Jakub Jelinek ---
(In reply to H.J. Lu from comment #8)
> Do you have a testcase to show decreasing DATA_ALIGNMENT would break
> backwards compatibility with older gcc versions?
Older GCC versions used DATA_ALIGNMENT (what is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296
--- Comment #8 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #7)
> See discussions when I've added DATA_ABI_ALIGNMENT.
DATA_ABI_ALIGNMENT was added for PR 56564:
/* Similar to DATA_ALIGNMENT, but for the cases where the ABI mandates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64331
--- Comment #1 from Senthil Kumar Selvaraj ---
Created attachment 34291
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34291&action=edit
Assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64331
Bug ID: 64331
Summary: regcprop propagates registers noted as REG_DEAD
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64330
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64330
Bug ID: 64330
Summary: [ASAN] Bogus "AddressSanitizer: odr-violation"
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64291
--- Comment #4 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #3)
> Started with r217587.
Oops, sorry for typo, r217588.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64291
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64265
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
1 - 100 of 123 matches
Mail list logo
