https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64683
--- Comment #4 from vries at gcc dot gnu.org ---
Ran into this failure with r219832.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64671
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
,ada,java,objc,c++,go,obj-c++
Thread model: posix
gcc version 5.0.0 20150119 (experimental) (GCC)
...
configure line bootstrap build (the same, but without --disable-bootstrap):
...
$ ./install/bin/gccgo -v
Using built-in specs.
COLLECT_GCC=./install/bin/gccgo
COLLECT_LTO_WRAPPER=/data/vries/ref
5.0.0 20150119 (experimental) [trunk revision 219832] (GCC)
$
$ gcc-trunk -O1 -c fn1.c
$ gcc-trunk -Os -c fn2.c
$ gcc-trunk -O0 -c main.c
$ gcc-trunk -O0 fn1.o fn2.o main.o
$ ./a.out
$
$
$ gcc-4.9 -flto -O1 -c fn1.c
$ gcc-4.9 -flto -Os -c fn2.c
$ gcc-4.9 -flto -O0 -c main.c
$ gcc-4.9 -flto fn1.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64683
--- Comment #2 from vries at gcc dot gnu.org ---
Created attachment 34495
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34495&action=edit
libgo.log (bootstrap build)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64683
--- Comment #1 from vries at gcc dot gnu.org ---
Created attachment 34494
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34494&action=edit
libgo.log (nobootstrap build)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64683
Bug ID: 64683
Summary: FAIL: runtime/pprof -- testing.go:278: The entry did
not match
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
P
: posix
gcc version 5.0.0 20150119 (experimental) [trunk revision 219832] (GCC)
$
$ gcc-trunk -Os small.c; a.out
5
$ gcc-4.9 -O2 small.c; a.out
5
$
$ gcc-trunk -O2 small.c; a.out
1
$
---
int printf (const char *, ...);
int a, b = 1;
int
main ()
{
int i;
for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57023
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
Ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63850
--- Comment #8 from Dmitry Vyukov ---
On Tue, Jan 20, 2015 at 9:06 AM, vekumar at gcc dot gnu.org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63850
>
> --- Comment #7 from vekumar at gcc dot gnu.org ---
> (In reply to clyon from commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64619
Mikhail Maltsev changed:
What|Removed |Added
CC||maltsevm at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63576
--- Comment #9 from Markus Trippelsdorf ---
I will give your patch a try.
In case it might help here's the script I use for LTO/PGO
(as you can see it starts the instrumented browser. I then
just visit a couple of webpages to train it):
markus@x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63576
--- Comment #8 from Jan Hubicka ---
Markus,
I don't seem to be able to train firefox with current tree because of unrelated
issues. If you would have chance to test the patch on your setup, it would be
cool.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63850
--- Comment #7 from vekumar at gcc dot gnu.org ---
(In reply to clyon from comment #6)
> Venkat,
> Can you submit your GCC patch, in an accepable way? (no change to sanitizer
> libs code, and obviously do not activate tsan by default)
Okay I will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64282
--- Comment #4 from Jan Hubicka ---
The reduced testcase does not seem to reproduce for me. The ICE is however
just overactive sanity check - the program is invalid and accesses random data
as vtable pointer. In this case we can just optimize to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64677
Mikhail Maltsev changed:
What|Removed |Added
CC||maltsevm at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #216 from Jan Hubicka ---
Author: hubicka
Date: Tue Jan 20 04:39:45 2015
New Revision: 219878
URL: https://gcc.gnu.org/viewcvs?rev=219878&root=gcc&view=rev
Log:
PR lto/45375
* i386.c (ix86_option_override_internal): Use ix86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64681
Bug ID: 64681
Summary: gcc assign wrong register for arm inline assembly
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64680
Bug ID: 64680
Summary: basic_regex::operator= does not reset flags
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48724
--- Comment #8 from Jan Hubicka ---
This no longer happens with recent Firefox builds, but I think it was rather
fixed at Firefox buildsystem...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64678
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59946
--- Comment #3 from Jeffrey A. Law ---
The m68000 does not support compare imm,pc-relative. Sadly the various
comparison patterns play things fast and loose in terms of what order they emit
their operands. That makes it nontrivial to write oper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64678
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Repro:
class Bar{
public:
Bar(int, int, int);
};
int main () {
int x = 1;
Bar bar(int(x), int(x), int{x});
}
gcc HEAD 5.0.0 20150119
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928
--- Comment #8 from DJ Delorie ---
There are a few regressions in the testsuite (pr26255.c with -mcpu=m32c for
example) and libstdc++ still doesn't build, but ieee/920810-1 now passes and
newlib builds. I suppose that's "better".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63576
--- Comment #7 from Jan Hubicka ---
Created attachment 34490
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34490&action=edit
Proposed fix
I am going to try build firefox with PDO myself with the attached patch. It is
bit tricky to merge t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63576
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #12 from Ian Lance Taylor ---
It's not libbacktrace that is crashing the app, it's libgo.
And, yes, probably libgo should not crash the app either. But it's also true
that many Go programs simply won't work correctly if file/line in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64678
Bug ID: 64678
Summary: Expected association error on dependent associate
statements
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: minor
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #11 from Andreas Schwab ---
But it shouldn't crash the app if you don't have the full information.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #10 from Ian Lance Taylor ---
The point of libbacktrace, at least if you call the backtrace_full function, is
to get file/line information. If you don't need file/line information, you can
just use _Unwind_Backtrace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #9 from Andrew Pinski ---
(In reply to Andreas Schwab from comment #8)
> Why does libbacktrace need debug info? All required unwind information is
> included in the binary. Glibc's backtrace can do that too.
Most likely the same re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #215 from Jan Hubicka ---
Author: hubicka
Date: Mon Jan 19 23:58:19 2015
New Revision: 219871
URL: https://gcc.gnu.org/viewcvs?rev=219871&root=gcc&view=rev
Log:
PR lto/45375
* i386.c (gate): Check flag_expensive_optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #8 from Andreas Schwab ---
Why does libbacktrace need debug info? All required unwind information is
included in the binary. Glibc's backtrace can do that too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #7 from Ian Lance Taylor ---
That failure is not related to the new gotools. I expect it would happen with
any Go program. Go requires that there be enough debug info to do a stack
backtrace with file/line information. It uses the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64652
--- Comment #3 from Oleg Endo ---
Author: olegendo
Date: Mon Jan 19 23:25:03 2015
New Revision: 219870
URL: https://gcc.gnu.org/viewcvs?rev=219870&root=gcc&view=rev
Log:
gcc/testsuite/
PR target/64652
* gcc.target/sh/torture/pr64652.c (t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64649
--- Comment #3 from Tim Shen ---
Author: timshen
Date: Mon Jan 19 23:12:37 2015
New Revision: 219869
URL: https://gcc.gnu.org/viewcvs?rev=219869&root=gcc&view=rev
Log:
PR libstdc++/64649
Backported from mainline
2015-01-19 Tim Shen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64584
--- Comment #2 from Tim Shen ---
Author: timshen
Date: Mon Jan 19 23:09:07 2015
New Revision: 219868
URL: https://gcc.gnu.org/viewcvs?rev=219868&root=gcc&view=rev
Log:
PR libstdc++/64584
PR libstdc++/64585
* include/bits/regex.h (bas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64585
--- Comment #2 from Tim Shen ---
Author: timshen
Date: Mon Jan 19 23:09:07 2015
New Revision: 219868
URL: https://gcc.gnu.org/viewcvs?rev=219868&root=gcc&view=rev
Log:
PR libstdc++/64584
PR libstdc++/64585
* include/bits/regex.h (bas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64649
--- Comment #2 from Tim Shen ---
Author: timshen
Date: Mon Jan 19 23:00:13 2015
New Revision: 219866
URL: https://gcc.gnu.org/viewcvs?rev=219866&root=gcc&view=rev
Log:
PR libstdc++/64649
* include/bits/regex.tcc (regex_traits<>::lookup_c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64585
--- Comment #1 from Tim Shen ---
Author: timshen
Date: Mon Jan 19 22:56:04 2015
New Revision: 219865
URL: https://gcc.gnu.org/viewcvs?rev=219865&root=gcc&view=rev
Log:
PR libstdc++/64584
PR libstdc++/64585
* include/bits/regex.h (bas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64584
--- Comment #1 from Tim Shen ---
Author: timshen
Date: Mon Jan 19 22:56:04 2015
New Revision: 219865
URL: https://gcc.gnu.org/viewcvs?rev=219865&root=gcc&view=rev
Log:
PR libstdc++/64584
PR libstdc++/64585
* include/bits/regex.h (bas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64672
Dominique d'Humieres changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64669
--- Comment #4 from Jiong Wang ---
haven't enable go front end,
../gcc/configure --enable-languages=c,c++,fortran --disable-libsanitizer
--enable-checking=release --disable-werror
with make -j16 profiledbootstrap, I got several
../../../gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |SUSPENDED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64645
--- Comment #5 from Bernd Edlinger ---
(In reply to Richard Henderson from comment #4)
> (In reply to Bernd Edlinger from comment #3)
> > AFAIK Cygwin-32 does not support the unwind info at all, right?.
>
> Wrong. This should be enough to fix i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59946
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64672
--- Comment #3 from howarth at bromo dot med.uc.edu ---
The attached reduced test case reproduces the ICE with...
$ ~/dist/bin/gfortran -fopenacc -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0 -g -flto asyncwait-1.f90
lto1: internal compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64672
--- Comment #2 from howarth at bromo dot med.uc.edu ---
Created attachment 34489
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34489&action=edit
minimal testcase to produce ICE on linux and darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36487
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36488
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53988
--- Comment #6 from Oleg Endo ---
Author: olegendo
Date: Mon Jan 19 22:35:53 2015
New Revision: 219864
URL: https://gcc.gnu.org/viewcvs?rev=219864&root=gcc&view=rev
Log:
gcc/
PR target/53988
* config/sh/sh-protos.h (sh_find_set_of_reg):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52714
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58369
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #10 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64669
--- Comment #3 from Jakub Jelinek ---
That was the --disable-werror.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63741
--- Comment #4 from Uroš Bizjak ---
(In reply to Joel Sherrill from comment #3)
> Added the dwarf maintainers hoping to get an answer. From an RTEMS
> perspective, the lm32 is not usable. Both 4.9 and the head are broken.
> Hoping you two have an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64668
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64674
--- Comment #2 from janus at gcc dot gnu.org ---
When commenting the line with 'CL%map', one gets a different ICE:
associate(CL => Cls(1))
1
internal compiler error: in gfc_conv_expr_descriptor, bei
fortran/trans-array.c:6499
0x692657 gfc_con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64669
--- Comment #2 from Richard Henderson ---
Hmm. I'm not even getting that far with r219852
gcc/expmed.h: In function ‘void init_expmed()’:
gcc/expmed.h:613:77: error: array subscript is above array bounds
[-Werror=array-bounds]
return &this_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64674
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64668
--- Comment #8 from Martin Liška ---
Fixed in 5.0.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64668
--- Comment #7 from Martin Liška ---
Author: marxin
Date: Mon Jan 19 22:02:04 2015
New Revision: 219861
URL: https://gcc.gnu.org/viewcvs?rev=219861&root=gcc&view=rev
Log:
Fix PR64668.
* objc/compile/pr64668.m: New test.
PR ipa/64668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64677
--- Comment #2 from Sanjay Patel ---
This is on plain x86-64 with SSE (before the addition of any FMA instructions),
so lack of FMA must be accounted for?
The answers differ in the last digit / ULP. Is there some standard or golden
implementatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64677
--- Comment #1 from Andrew Pinski ---
One part is different. Most likely not a bug. Division really depends on
fused multiple add to get good results IIRC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64676
--- Comment #5 from David Edelsohn ---
This was caused by r219842
PR rtl-optimization/64081
* loop-iv.c (def_pred_latch_p): New function.
(latch_dominating_def): Allow specific cases with non-single
definitions.
(iv_get_reach
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435
--- Comment #21 from Jakub Jelinek ---
Ugh, there is also this junk:
// By default we allow to use SizeClassAllocator64 on 64-bit platform.
// But in some cases (e.g. AArch64's 39-bit address space) SizeClassAllocator64
// does not work well and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57023
--- Comment #5 from Thomas Koenig ---
I have something. Let's see if it works...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64677
Bug ID: 64677
Summary: incorrect result with complex division?
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63741
--- Comment #3 from Joel Sherrill ---
Added the dwarf maintainers hoping to get an answer. From an RTEMS perspective,
the lm32 is not usable. Both 4.9 and the head are broken. Hoping you two have
an idea. Happy to help since this is a cross targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
--- Comment #14 from Harald Anlauf ---
Created attachment 34488
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34488&action=edit
Updated partial patch
This modified partial patch addresses the potential performance issue by
calling the _4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64218
--- Comment #15 from Jan Hubicka ---
Author: hubicka
Date: Mon Jan 19 20:46:15 2015
New Revision: 219859
URL: https://gcc.gnu.org/viewcvs?rev=219859&root=gcc&view=rev
Log:
PR ipa/64218
* ipa-inline.c (want_inline_function_to_all_callers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63850
--- Comment #6 from clyon at gcc dot gnu.org ---
Venkat,
Can you submit your GCC patch, in an accepable way? (no change to sanitizer
libs code, and obviously do not activate tsan by default)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64218
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64675
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64664
Markus Trippelsdorf changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64676
--- Comment #4 from David Edelsohn ---
Sorry, first use of the stage 2 compiler that presumably was miscompiled by
stage 1 compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64676
--- Comment #3 from David Edelsohn ---
Configure libgcc in stage 2. The first use of the stage 1 compiler.
r219827 bootstrapped successfully.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64671
--- Comment #3 from Vladimir Makarov ---
Author: vmakarov
Date: Mon Jan 19 20:13:35 2015
New Revision: 219857
URL: https://gcc.gnu.org/viewcvs?rev=219857&root=gcc&view=rev
Log:
2015-01-19 Vladimir Makarov
PR rtl-optimization/64671
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435
--- Comment #20 from clyon at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #14)
>
> https://github.com/torvalds/linux/blob/master/arch/arm64/include/asm/memory.h
> https://github.com/torvalds/linux/blob/master/arch/arm64/Kconfig
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64676
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64459
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64671
--- Comment #2 from Vladimir Makarov ---
I started to work on this. The patch will be in the trunk today. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64645
--- Comment #4 from Richard Henderson ---
(In reply to Bernd Edlinger from comment #3)
> AFAIK Cygwin-32 does not support the unwind info at all, right?.
Wrong. This should be enough to fix it.
diff --git a/src/x86/sysv.S b/src/x86/sysv.S
inde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64645
--- Comment #3 from Bernd Edlinger ---
OK.
AFAIK Cygwin-32 does not support the unwind info at all, right?.
Cygwin-64 does support Windows-SEH style unwind info.
libjava uses a kind of hack to get the stack trace:
see libjava/sysdep/i386/backt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64676
David Edelsohn changed:
What|Removed |Added
Target||powerpc-ibm-aix*
Status|UNC
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
$ cat conftest.c
int
main ()
{
;
return 0;
}
(gdb) run -O conftest.c
Starting program: /tmp/20150119/gcc/cc1 -O conftest.c
main
Analyzing compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64645
Richard Henderson changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64642
--- Comment #2 from Markus Eisenmann ---
I do not (completely) agree, that the code/result is undefined. Of course, this
sample doesn’t make any sense and shouldn’t never occur (in a similar form).
But - in this case - the C-style cast, like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64640
Bernd Edlinger changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64640
--- Comment #2 from Bernd Edlinger ---
Author: edlinger
Date: Mon Jan 19 19:00:18 2015
New Revision: 219855
URL: https://gcc.gnu.org/viewcvs?rev=219855&root=gcc&view=rev
Log:
2015-01-19 Bernd Edlinger
PR ada/64640
* adaint.c:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435
--- Comment #19 from Jakub Jelinek ---
So, with:
--- libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h.jj
2014-11-14 00:10:33.0 +0100
+++ libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
2015-01-19 19:22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64632
--- Comment #2 from Jonathan Wakely ---
This just does the same std::ios_base::_M_streambuf_state member directly
rather than through the basic_ios::rdstate() member function (compile
with -fno-access-control)
#include
int main()
{
std::ofst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435
--- Comment #18 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #17)
> PPC64 actually supports both 44 and 46 bit address space:
>
> uptr GetMaxVirtualAddress() {
> #if SANITIZER_WORDSIZE == 64
> # if defined(__powerpc64__)
> //
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64664
Martin Liška changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64664
--- Comment #2 from Martin Liška ---
Author: marxin
Date: Mon Jan 19 18:07:08 2015
New Revision: 219853
URL: https://gcc.gnu.org/viewcvs?rev=219853&root=gcc&view=rev
Log:
Fix PR64664.
PR ipa/64664
* ipa-icf.c (sem_item_optimizer::fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435
--- Comment #17 from Jakub Jelinek ---
PPC64 actually supports both 44 and 46 bit address space:
uptr GetMaxVirtualAddress() {
#if SANITIZER_WORDSIZE == 64
# if defined(__powerpc64__)
// On PowerPC64 we have two different address space layouts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64607
--- Comment #5 from Richard Henderson ---
Author: rth
Date: Mon Jan 19 17:58:06 2015
New Revision: 219852
URL: https://gcc.gnu.org/viewcvs?rev=219852&root=gcc&view=rev
Log:
PR libffi/64607
* testsuite/lib/libffi.exp (libffi-init): Append -L fo
1 - 100 of 184 matches
Mail list logo
