https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64833
--- Comment #12 from Kazumoto Kojima ---
I could reproduce the problem on trunk with '-DXS_VERSION=\"6.89\" -fwrapv
-fno-strict-aliasing -fopenmp -O2 -fstack-protector-strong -fexceptions -fPIC'
with the cross sh4-unknown-linux-gnu compiler.
It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64833
--- Comment #11 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #9)
> Created attachment 35870 [details]
> Pre-processed source Magick.i
I've tried compiling that file with '-x c -std=gnu99 -O2 -g -fPIC -m4
-DXS_VERSION=\"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66687
--- Comment #8 from Andrew Pinski ---
(In reply to Guido Haztsis from comment #6)
> (In reply to H.J. Lu from comment #5)
> > (In reply to Andrew Pinski from comment #4)
> > > MUSL support is not included in GCC 5.x is another thing. Also you ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64130
--- Comment #11 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Mon Jun 29 00:15:41 2015
New Revision: 225108
URL: https://gcc.gnu.org/viewcvs?rev=225108&root=gcc&view=rev
Log:
gcc/ChangeLog:
2015-06-29 Kugan Vivekanandarajah
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66694
Bug ID: 66694
Summary: Failure in function returning an allocated CHARACTER
array
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66687
--- Comment #7 from H.J. Lu ---
(In reply to Guido Haztsis from comment #6)
> I am pretty sure it can be reproduced without any libc. Actually, for some
> reason the libc.a file isn't even in the res file. This used to appear in
> the 5.1 version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66687
--- Comment #6 from Guido Haztsis ---
(In reply to H.J. Lu from comment #5)
> (In reply to Andrew Pinski from comment #4)
> > MUSL support is not included in GCC 5.x is another thing. Also you are
> > using x32 which is not tested that much.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64833
--- Comment #10 from John Paul Adrian Glaubitz ---
Created attachment 35871
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35871&action=edit
Source file Magick.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64833
--- Comment #9 from John Paul Adrian Glaubitz ---
Created attachment 35870
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35870&action=edit
Pre-processed source Magick.i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64833
--- Comment #8 from John Paul Adrian Glaubitz ---
Alright, know that I understand how to create pre-processed sources manually,
I'm attaching the requested pre-processed sources.
Here's how I obtained the pre-processed source. From my point of v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620
--- Comment #12 from Chen Gang ---
Created attachment 35869
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35869&action=edit
The result before lsetup optimization
The lsetup information is below:
lsetup (loop_begin, loop_end) count.
R0 w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620
--- Comment #11 from Chen Gang ---
Created attachment 35868
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35868&action=edit
The result when without "-fno-reorder-block"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620
--- Comment #10 from Chen Gang ---
Created attachment 35867
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35867&action=edit
The result after skip the assert() for having "-fno-reorder-block"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620
--- Comment #9 from Chen Gang ---
After check the assembly result for the without "-fno-reorder-block", it is OK.
It is for lsetup optimization.
And for having "-fno-reorder-block", the insns are also correct, and after skip
the related assert()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66692
Arnaud Charlet changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66693
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66689
--- Comment #2 from Jonathan Wakely ---
Thanks for the analysis.
I'd like to re-use the TR1 code for an implementation of ISO/IEC 29124:2010
(whether or not it also goes into C++17) so we should fix this first.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66690
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64833
--- Comment #7 from Oleg Endo ---
Is there any update regarding this issue? Adrian, were you able to get a
preprocessed source file which reproduces the problem?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #7 from Mikael Pettersson ---
The test case in comment #0 stopped breaking on trunk with r221077, the fix for
PR65236 (a gcc-5 IPA regression). Backporting r221077 to 4.9.3 unbreaks this
test case there. However:
- I can't get this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66689
--- Comment #1 from John Maddock ---
I think I've found the problem - make the nu parameter negative and you get the
correct answers.
These functions appear to use the same definition for ellint_3 as GSL uses
(same code?), but TR1 uses a differe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66682
Mikhail Maltsev changed:
What|Removed |Added
Known to work||4.9.0
--- Comment #8 from Mikhail Malt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66693
Bug ID: 66693
Summary: [C++17] std::tuple_size fails with const std::array
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66691
--- Comment #4 from Markus Trippelsdorf ---
-fno-lra-remat "fixes" the issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66692
Bug ID: 66692
Summary: gcc-4.9 fails to compile with gcc-5.1.0
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620
--- Comment #8 from Chen Gang ---
Created attachment 35866
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35866&action=edit
Full insns for without "-fno-reorder-blocks".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620
--- Comment #7 from Chen Gang ---
(In reply to Chen Gang from comment #2)
> (In reply to Mikhail Maltsev from comment #1)
> > Started with r208165.
>
> OK, thanks. Really it is, it is valuable to me (it can generate the correct
> insns for compa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940
--- Comment #48 from asmwarrior ---
Hi, Martin Richter, thanks, I have post this patch link in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926
--- Comment #19 from asmwarrior ---
Martin Richter has post a patch to solve this issue, see: [Comment
47](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940#c47), also there are
some discussion in [MinGW-w64 - for 32 and 64 bit Windows / Bugs /
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66691
Uroš Bizjak changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66691
--- Comment #2 from Uroš Bizjak ---
Confirmed, I have to use:
cc1 -m32 -O3 -g -mtune=generic -march=i686
Breakpoint 1, internal_error (gmsgid=gmsgid@entry=0x163d677 "in %s, at %s:%d")
at /home/uros/gcc-svn/trunk/gcc/diagnostic.c:1266
1266{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66691
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66614
--- Comment #3 from Bernd Edlinger ---
I checked a few apps, and have not yet found any impact of the return
value of rtx_addr_can_trap_p_1 on the final code so far.
That means that this is probably only a low prio bug...
Regarding the LRA, I t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #38 from Kazumoto Kojima ---
Author: kkojima
Date: Sun Jun 28 07:02:47 2015
New Revision: 225104
URL: https://gcc.gnu.org/viewcvs?rev=225104&root=gcc&view=rev
Log:
PR target/66563
* [SH] Add a new operand to GOTaddr2picreg so to avoi
34 matches
Mail list logo
