http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
--- Comment #12 from Zhendong Su ---
(In reply to Jeffrey A. Law from comment #11)
> I know what's happening here. It's obscure and quite nasty.
>
> We have a jump threading opportunity which requires threading through a
> joiner block. The jum
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58409
Bug ID: 58409
Summary: wrong reordering of volatile writes
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
As
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58409
--- Comment #1 from Andrew Pinski ---
Does:
g_3[0][0][0].f1 = (**g_4).f1;
Fix the issue if so it is a dup of bug 47409 really.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58314
--- Comment #2 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Fri Sep 13 07:51:07 2013
New Revision: 202557
URL: http://gcc.gnu.org/viewcvs?rev=202557&root=gcc&view=rev
Log:
2013-09-13 Christian Bruel
PR target/58314
* c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
Matt Clarkson changed:
What|Removed |Added
CC||mattyclarkson at gmail dot com
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
--- Comment #13 from Matt Clarkson ---
Created attachment 30814
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30814&action=edit
missing dllexport on typeinfo output
Added an attachment for the full compiler output.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58314
--- Comment #3 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Fri Sep 13 08:38:22 2013
New Revision: 202559
URL: http://gcc.gnu.org/viewcvs?rev=202559&root=gcc&view=rev
Log:
2013-09-13 Christian Bruel
PR target/58314
* c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58314
chrbr at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58410
--- Comment #1 from Vladimir Fuka ---
Created attachment 30815
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30815&action=edit
uninit.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58410
Bug ID: 58410
Summary: Bogus uninitialized variable warning for allocatable
derived type array function result
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58411
Bug ID: 58411
Summary: no_sanitize_undefined function attribute
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: sani
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58411
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58409
--- Comment #2 from Francesco Zappa Nardelli ---
Yes, it does fix the issue.
So this reordering is another effect of gcc not considering accessing volatile
fields in non-volatile structs as volatile access (as in bug 47409). Can I ask
about gc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58412
Bug ID: 58412
Summary: C++11 : numeric_limits::stuff must be constexpr
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58412
--- Comment #1 from Marc Glisse ---
It's already the case in recent versions, isn't it?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58409
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58412
--- Comment #2 from Marc Glisse ---
I think you forgot () after quiet_NaN and got confused by the error message.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47409
--- Comment #17 from Richard Biener ---
*** Bug 58409 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58413
Bug ID: 58413
Summary: ubsan constant folding
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assigne
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47409
--- Comment #18 from Richard Biener ---
(In reply to Francesco Zappa Nardelli from comment #16)
> Dear all
>
> a possibly related issue. Consider
>
> struct S1 {
> long f;
> };
> volatile struct S1 g;
>
> struct S1 func_1 () {
> return g;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58413
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58388
Martin Jambor changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47409
--- Comment #19 from Francesco Zappa Nardelli ---
>> does not perform the volatile load access.
> It does starting with GCC 4.8.2 and was a bug in older GCC versions.
I just tested my example (comment 16) against yesterday trunk
gcc version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58407
--- Comment #6 from Andrzej Krzemienski ---
(In reply to Andrzej Krzemienski from comment #2)
> No. Other compilers (Clang and VS 2010) do not emit such warning either.
Correction: The newest version of Clang does give a warning:
"definition of i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58412
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
Markus Trippelsdorf changed:
What|Removed |Added
CC||markus at trippelsdorf dot de
--- C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58367
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58408
--- Comment #1 from Jonathan Wakely ---
If you make it constexpr, which requires you to initialize the member, then it
works:
class Test {
public:
constexpr Test() = default;
Test(char *b) { }
int i = 0;
};
Clang accepts both that and your
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47409
--- Comment #20 from Richard Biener ---
(In reply to Francesco Zappa Nardelli from comment #19)
> >> does not perform the volatile load access.
>
> > It does starting with GCC 4.8.2 and was a bug in older GCC versions.
>
> I just tested my examp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58388
--- Comment #6 from Martin Jambor ---
Author: jamborm
Date: Fri Sep 13 12:04:54 2013
New Revision: 202563
URL: http://gcc.gnu.org/viewcvs?rev=202563&root=gcc&view=rev
Log:
2013-09-13 Martin Jambor
PR bootstrap/58388
* ipa-prop.c (try_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58392
--- Comment #6 from Jakub Jelinek ---
Author: jakub
Date: Fri Sep 13 12:42:04 2013
New Revision: 202564
URL: http://gcc.gnu.org/viewcvs?rev=202564&root=gcc&view=rev
Log:
PR tree-optimization/58392
* tree-cfg.c (move_sese_region_to_fn): Re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58392
--- Comment #7 from Jakub Jelinek ---
Author: jakub
Date: Fri Sep 13 12:46:32 2013
New Revision: 202565
URL: http://gcc.gnu.org/viewcvs?rev=202565&root=gcc&view=rev
Log:
PR tree-optimization/58392
* testsuite/libgomp.c/pr58392.c: New test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55342
--- Comment #10 from Yuri Rumyantsev ---
After fix rev. 202468 assembly looks slightly better but we met with another RA
inefficiency which can be illustrated on the attached (t1.c) test compiled with
options "-march=atom -mtune=atom -m32 -O2" tha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55342
--- Comment #11 from Yuri Rumyantsev ---
Created attachment 30816
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30816&action=edit
test-case to reproduce
t1.c must be compiled on x86 with options:
-O2 -march=atom -mtune=atom -mfpmath=sse -m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58388
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58094
--- Comment #6 from Jan Hubicka ---
Author: hubicka
Date: Fri Sep 13 14:35:32 2013
New Revision: 202567
URL: http://gcc.gnu.org/viewcvs?rev=202567&root=gcc&view=rev
Log:
PR middle-end/58094
* ipa-inline.c (check_callers): New function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47409
--- Comment #21 from Francesco Zappa Nardelli ---
(In reply to Richard Biener from comment #20)
> > However the code I reported in bug 58409, which has been marked duplicate of
> > this bug, still exhibits the incorrect reordering of volatile acc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58414
Bug ID: 58414
Summary: String.format("%9d",(Long)null) returns null-pointer
exception
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
--- Comment #15 from Zhendong Su ---
(In reply to Jeffrey A. Law from comment #14)
> It's the action of executing the code with undefined behaviour which is the
> trigger. ie, if you don't execute the code, then it has no effect on the
> defined/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
--- Comment #18 from Jeffrey A. Law ---
I'll also note that the plan for the isolated paths that exhibit undefined
behaviour is to have them trap/abort at the statement which triggers the
undefined behaviour.
The original patch from 2011 actually
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
--- Comment #14 from Jeffrey A. Law ---
It's the action of executing the code with undefined behaviour which is the
trigger. ie, if you don't execute the code, then it has no effect on the
defined/undefined state of the program as a whole.
It's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848
--- Comment #21 from Whitequill Riclo ---
The patch worked for me, but now I'm getting a new error that looks like Bug
47052 accept the proposed fix doesn't work because is says DW2 isn't suppored
on 64-bit yet.
I can get around this if I change
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
--- Comment #16 from Jeffrey A. Law ---
The optimization came out of building additional warnings for GCC. It's safe
to assume that there'll be an option to enable a warning that the compiler was
able to identify and isolate a path with undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57850
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58415
Bug ID: 58415
Summary: __sso_string_base move constructor does not null
terminate local data when moving from empty string
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
--- Comment #17 from joseph at codesourcery dot com ---
On Fri, 13 Sep 2013, su at cs dot ucdavis.edu wrote:
> I noticed a stackoverflow discussion on this very topic:
>
> http://stackoverflow.com/questions/7961067/how-undefined-is-undefined-be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
--- Comment #19 from Marc Glisse ---
(In reply to Jeffrey A. Law from comment #18)
> I'll also note that the plan for the isolated paths that exhibit undefined
> behaviour is to have them trap/abort at the statement which triggers the
> undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58415
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58415
--- Comment #4 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Fri Sep 13 18:32:42 2013
New Revision: 202574
URL: http://gcc.gnu.org/viewcvs?rev=202574&root=gcc&view=rev
Log:
2013-09-13 Paolo Carlini
PR libstdc++/58415
* include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58415
--- Comment #5 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Fri Sep 13 18:33:17 2013
New Revision: 202575
URL: http://gcc.gnu.org/viewcvs?rev=202575&root=gcc&view=rev
Log:
2013-09-13 Paolo Carlini
PR libstdc++/58415
* include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58415
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58415
--- Comment #3 from Paolo Carlini ---
Ok, thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58415
--- Comment #2 from Michael Kirzinger ---
There appears to be one additional problem: if __rcs._M_is_local() is true, but
__rcs._M_length() is false, the buffer of the string being created is never
null terminated/zeroed.
Example:
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848
--- Comment #22 from Kai Tietz ---
Author: ktietz
Date: Fri Sep 13 17:28:25 2013
New Revision: 202572
URL: http://gcc.gnu.org/viewcvs?rev=202572&root=gcc&view=rev
Log:
PR target/57848
* c-decl.c (c_builtin_function_ext_scope): Remove
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848
Kai Tietz changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50909
Dean Churchill changed:
What|Removed |Added
CC||dc7000 at att dot com
--- Comment #3 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
--- Comment #20 from Jeffrey A. Law ---
I think an option to eliminate the path entire like the first iteration of the
change did could be easily added later. In fact it would be fairly easy to
add.
Basically we'd arrange to mark the isolated pa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50909
--- Comment #4 from Dominique d'Humieres ---
> I am trying to apply this patch on OSX Lion (10.8.5) to gcc 4.6.2,
> but the diff command on OSX doesn't accept the --git option,
> and am not sure how to rewrite the patch for Lion. Can you help?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58273
--- Comment #3 from Jason Merrill ---
Author: jason
Date: Fri Sep 13 19:11:23 2013
New Revision: 202576
URL: http://gcc.gnu.org/viewcvs?rev=202576&root=gcc&view=rev
Log:
PR c++/58273
* pt.c (any_type_dependent_elements_p): Actually check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57850
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
--- Comment #21 from Marc Glisse ---
Thanks Jeff, sounds great :-)
Even if we mark that a statement is not reachable, we probably won't eliminate
many functions with side-effects executed before, since (I guess) we must be
able to prove that they
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57850
--- Comment #9 from Jason Merrill ---
Created attachment 30818
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30818&action=edit
patch
Can you verify that this patch fixes the issue?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58413
--- Comment #2 from Marek Polacek ---
A patch that hopefully fixes the integer constant expression issues posted:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01057.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
Bug ID: 58416
Summary: Incorrect x87-based union copying code
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50909
--- Comment #5 from Dean Churchill ---
That worked. thanks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58417
Bug ID: 58417
Summary: Incorrect optimization
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57657
Jorge Aparicio changed:
What|Removed |Added
CC||jorge.aparicio.r at gmail dot
com
--- C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57657
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #1 from H.J. Lu ---
This may be related to PR57484.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400
Jeffrey A. Law changed:
What|Removed |Added
CC||kazu at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400
--- Comment #6 from Jeffrey A. Law ---
Reduced testcase:
static __inline__ __attribute__((always_inline))
__attribute__((no_instrument_function)) int test_bit(int nr, const unsigned
long* addr)
{
return (*((volatile unsigned char *)addr +
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58401
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400
--- Comment #7 from Jeffrey A. Law ---
*** Bug 58401 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57657
H.J. Lu changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
--with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk
--with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk
--prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20130913 (experimental) [trunk revision 202556] (GCC)
$
$ gcc-trunk -m32 -O1 small.c
$ a.out
0
$ gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58256
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58417
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58418
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55860
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #2 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58273
--- Comment #4 from Jason Merrill ---
Author: jason
Date: Fri Sep 13 22:22:31 2013
New Revision: 202580
URL: http://gcc.gnu.org/viewcvs?rev=202580&root=gcc&view=rev
Log:
PR c++/58273
* pt.c (any_type_dependent_elements_p): Actually check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58273
--- Comment #5 from Jason Merrill ---
Author: jason
Date: Fri Sep 13 22:38:42 2013
New Revision: 202583
URL: http://gcc.gnu.org/viewcvs?rev=202583&root=gcc&view=rev
Log:
PR c++/58273
* pt.c (any_type_dependent_elements_p): Actually check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58273
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk
--prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20130913 (experimental) [trunk revision 202556] (GCC)
$ gcc-trunk -m32 -O2 small.c
$ a.out
0
$ gcc-4.8 -m32 -O3 small.c
$ a.out
0
$ gcc-trunk -m64 -O3 small.c
$ a.out
0
$ gcc-trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58420
Bug ID: 58420
Summary: internal compiler error: in ubsan_type_descriptor, at
ubsan.c:280
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58419
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58419
--- Comment #2 from Zhendong Su ---
(In reply to H.J. Lu from comment #1)
> It is caused by r202468.
So it may have been a dup of 58418?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58420
--- Comment #1 from Jan Smets ---
This may be because of the (not yet committed) patch for ubsan vla bounds
checking.
http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg61427.html
Probably another one for Marek Polacek.
- Jan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58411
--- Comment #2 from Jan Smets ---
Please also think of the other -fsanitize= options.
89 matches
Mail list logo
