https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #100 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #99)
> Hm .. those don't fail on sh-elf ... maybe something related to the atomics?
> Atomics are off by default for sh-elf, but on for sh-linux.
Maybe. It could be s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #99 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #98)
> I guess that these pr64661-x.c regressions are not so problem, though.
I agree.
> I'm not sure whether hiconst.c regression is serious or not.
I think we can i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67365
--- Comment #3 from Ian Lance Taylor ---
The missing address is part of the signal handling code. It's the code that
returns to normal execution after the signal handler completes, by calling the
rt_sigreturn system call. The backtrace code rou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67555
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #98 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #97)
> I've compared the results of r227512 without LRA and r227682 with LRA.
> Below are the new failures.
A typical example of pr64661-x.c regressions is:
[LRA]
test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67556
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67556
Bug ID: 67556
Summary: Regex \w doesn't support the unicode character
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67363
--- Comment #20 from Rainer Emrich ---
(In reply to İsmail Dönmez from comment #18)
> (In reply to John David Anglin from comment #17)
> > Fixed on hppa*-*-hpux*.
>
> Also fixes mingw-w64, thank you!
Confirmed, bootstraps on native x84_64-w64-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67546
Rainer Emrich changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67363
Rainer Emrich changed:
What|Removed |Added
CC||rai...@emrich-ebersheim.de
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
--- Comment #8 from Mark Wielaard ---
Submitted a patch:
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00847.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
--- Comment #35 from Dominique d'Humieres ---
I get
[Book15] f90/bug% /opt/gcc/gcc6p-227264p1/bin/gfortran -Ofast pr14741.f90
-floop-interchange -march=native -Wa,-q
[Book15] f90/bug% time a.out
0.487283
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47679
--- Comment #22 from Jeffrey A. Law ---
Author: law
Date: Fri Sep 11 21:32:38 2015
New Revision: 227697
URL: https://gcc.gnu.org/viewcvs?rev=227697&root=gcc&view=rev
Log:
[PATCH] Another small cleanup to the const_and_copies stack
2015-09-11 J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66640
--- Comment #2 from Lorenz Hüdepohl ---
(In reply to Dominique d'Humieres from comment #1)
> I cannot reproduce this PR on darwin (no addr2line).
>
> Could you check that this has not been fixed on a recent version of trunk
> (6.0): post r227503
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
--- Comment #34 from Sebastian Pop ---
r227567 extends the limits of a scop, and now we can detect a scop in the
MAIN__ function corresponding to the following code:
A=0.1D0
B=0.1D0
-fdump-tree-graphite-all shows that the loops have been ti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67553
--- Comment #2 from tmb99 at gmx dot net ---
seems to be the same for most saturating instructions:
__m128i v0 = _mm_setzero_si128();
__m128i v2 = _mm_setzero_si128();
__m128i sum = _mm_adds_epi16(v0,v2);
__m128i dif = _mm_subs_epi8(v0,v2);
__m12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67555
--- Comment #1 from Claudio Ebel ---
Created attachment 36326
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36326&action=edit
Unprocessed source file / minimal test case (30 lines)
Preprocessed sourcefile was too big for bugzilla and past
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67555
Bug ID: 67555
Summary: Emplacement of random numbers in vector displaces
other variables (loop counter)
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67192
--- Comment #11 from Andreas Arnez ---
Any news here? AFAIK the problem still exists.
), %mm0
addq$-128, %rsp
packsswby(%rip), %mm0
movq%mm0, x(%rip)
ret
.cfi_endproc
.LFE0:
.size fn1, .-fn1
.section.text.unlikely
.LCOLDE0:
.text
.LHOTE0:
.ident "GCC: (GNU) 5.2.1 20150911"
.
fn1
.section.text.unlikely
.LCOLDE1:
.text
.LHOTE1:
.ident "GCC: (GNU) 5.2.1 20150911"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 interrupt-1]$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67554
Bug ID: 67554
Summary: runtime error in valarray (NULL passed to memcpy)
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67553
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #22 from Manuel López-Ibáñez ---
(In reply to baoshan from comment #21)
> Don't you think the range value is strange? how it is possible the range
> value is so big according the code?
j = i - 1 is actually j = i + 4294967295 because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67548
--- Comment #4 from H.J. Lu ---
It is wrong to clear DECL_WEAK:
DECL_WEAK (next->decl) = false;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67553
Bug ID: 67553
Summary: Saturating SSE/AVX instructions do not get optimized
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67548
--- Comment #3 from H.J. Lu ---
We have
enum ld_plugin_symbol_resolution
{
LDPR_UNKNOWN = 0,
/* Symbol is still undefined at this point. */
LDPR_UNDEF,
/* This is the prevailing definition of the symbol, with references from
regu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #21 from baoshan ---
(In reply to Manuel López-Ibáñez from comment #20)
> (In reply to baoshan from comment #19)
> > We can see the value of up_sub is represented as unsigned int value
> > 4294967291 which is really weird to me, it su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67550
Markus Trippelsdorf changed:
What|Removed |Added
Keywords||wrong-code
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #97 from Oleg Endo ---
(In reply to Oleg Endo from comment #96)
>
> I haven't tried yet. I will do a full toolchain rebuild and test with -mlra
> enabled by default.
I've compared the results of r227512 without LRA and r227682 with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67551
--- Comment #4 from porten at kde dot org ---
Right. Usage of #line would be nicer. But if the additional bytes just slow
down things...
The recommended -fpreprocessed appears to be a good workaround. Does it maybe
even speed up the compilation?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67552
--- Comment #2 from H.J. Lu ---
Red zone isn't supported in interrupt handler:
'interrupt'
Use this attribute to indicate that the specified void function
without arguments is an interrupt handler. The compiler generates
function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67552
--- Comment #1 from H.J. Lu ---
Created attachment 36324
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36324&action=edit
A patch to remove railing whitespaces in interrupt-switch-abi.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67551
Andrew Pinski changed:
What|Removed |Added
Summary|Preprocessor generates |Option for the Preprocessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67552
Bug ID: 67552
Summary: [meta] x86 interrupt attribute
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67551
--- Comment #2 from Andrew Pinski ---
You can also use -P to get rid of the line markers from the processor output
which avoids your warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67551
--- Comment #1 from Andrew Pinski ---
Or you could use -fpreprocessed as another option which is the same as doing
.i.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67551
Bug ID: 67551
Summary: Preprocessor generates non-ISO line directives
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67550
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67173
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|6.0 |5.3
--- Comment #4 from Jonathan Wakel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67173
--- Comment #3 from Jonathan Wakely ---
Author: redi
Date: Fri Sep 11 14:20:32 2015
New Revision: 227689
URL: https://gcc.gnu.org/viewcvs?rev=227689&root=gcc&view=rev
Log:
Fix filesystem::canonical on Solaris 10.
PR libstdc++/67173
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67550
Bug ID: 67550
Summary: Initialization of local struct array with elements of
global array yields zeros instead of initializer
values
Product: gcc
Version: 5.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67173
--- Comment #2 from Jonathan Wakely ---
Oops, I'm leaking the memory allocated by realpath() so that needs fixing
anyway.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67173
--- Comment #1 from Jonathan Wakely ---
Solaris 10 doesn't support realpath(path, NULL) as used in
filesystem::canonical() so we need to allocate a buffer for it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67531
--- Comment #5 from Pat Haugen ---
(In reply to Francois-Xavier Coudert from comment #3)
> How about with this? I'm trying to come as close as possible to the exact
> sequence of fe.etround() calls as the Fortran front-end and runtime library
> w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59478
--- Comment #1 from Oleg Endo ---
(In reply to Oleg Endo from comment #0)
> This happens at least on SH with trunk rev 205905 (4.9).
> I'm not sure whether these are target specific or not.
>
> Accessing float values as integers can be done in v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65142
--- Comment #3 from Jonathan Wakely ---
Author: redi
Date: Fri Sep 11 13:44:26 2015
New Revision: 227687
URL: https://gcc.gnu.org/viewcvs?rev=227687&root=gcc&view=rev
Log:
Check read() result in std::random_device.
PR libstdc++/65142
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65142
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |5.3
--- Comment #2 from Jonathan Wakel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65142
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67509
--- Comment #6 from Andreas Schwab ---
With that patch the test passes on all opt levels.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67546
--- Comment #6 from Kai Tietz ---
Initially in PR/67363 just the missing strndup due failed libiberty-linking was
noticed. Later comments are duplicate of this.
So feel free to mark one of these bugs as duplicate, if you prefer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67096
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67546
--- Comment #5 from David Malcolm ---
Is this a duplicate of PR 67363?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67096
--- Comment #2 from Jonathan Wakely ---
Author: redi
Date: Fri Sep 11 13:06:42 2015
New Revision: 227686
URL: https://gcc.gnu.org/viewcvs?rev=227686&root=gcc&view=rev
Log:
Fix invalid UTF-8 in wchar_t tests.
2015-09-11 John Marino
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67548
--- Comment #2 from H.J. Lu ---
This may be a linker bug if it tells GCC that a weak symbol is
prevailing with "ld -r".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67095
--- Comment #2 from BENAÏSSA ---
Thank you for your reply. A.Benaïssa.
Le Dimanche 2 août 2015 13h46, pinskia at gcc dot gnu.org
a écrit :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67095
Andrew Pinski changed:
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67548
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64857
--- Comment #3 from Jonathan Wakely ---
Author: redi
Date: Fri Sep 11 12:25:43 2015
New Revision: 227684
URL: https://gcc.gnu.org/viewcvs?rev=227684&root=gcc&view=rev
Log:
Rationalise PCH headers and 17_intro/headers tests.
PR libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64857
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67549
--- Comment #1 from Andrew Pinski ---
4.8.x is no longer support, can you try 4.9.x and above?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67547
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67549
Bug ID: 67549
Summary: internal compiler error: in fold_binary_loc
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67548
Bug ID: 67548
Summary: [5/6 Regression] LTO drops weak binding with "ld -r"
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67547
Bug ID: 67547
Summary: may be an error in printf(%a..) for
nexttowardf(0.f,1.f)
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67096
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #96 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #95)
>
> I think that it's OK to make LRA default on trunk, even if it's
> better with your R0 pre-allocating pass.
The R0 pre-alloc pass could be a further improvemen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #95 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #94)
> Kaz, do you think we can enable LRA by default for GCC 6?
I think that it's OK to make LRA default on trunk, even if it's
better with your R0 pre-allocating pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #94 from Oleg Endo ---
Kaz, do you think we can enable LRA by default for GCC 6?
Some early results from the AMS optimization show new R0 spill failures. For
example, AMS uses @(R0,Rn) address modes more often. Although I still wou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58517
--- Comment #7 from Oleg Endo ---
(In reply to ktkachov from comment #6)
> Huh, I wasn't aware of this BZ.
> This looks eerily similar to what I think is the root cause of PR 67481,
> which I'm working on now.
>
> After I'm done with PR 67481 it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66902
--- Comment #7 from Vadim Zhukov ---
(In reply to Jonathan Wakely from comment #6)
> 3.5 [basic.link]:
>
> -3- A name having namespace scope (3.3.6) has internal linkage if it is the
> name of
> — a variable, function or function tem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58517
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64883
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|redi at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58265
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58265
--- Comment #9 from Jonathan Wakely ---
Author: redi
Date: Fri Sep 11 11:02:14 2015
New Revision: 227681
URL: https://gcc.gnu.org/viewcvs?rev=227681&root=gcc&view=rev
Log:
Implement N4258 noexcept for std::basic_string.
PR libstdc++/582
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67506
--- Comment #10 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #9)
>
> Thanks for the quick bug fix! Matthias already uploaded a new gcc-5 snapshot
> today which contains the fix :).
I guess it will take a while until yo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67476
vries at gcc dot gnu.org changed:
What|Removed |Added
Keywords||patch
--- Comment #4 from vrie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58517
Oleg Endo changed:
What|Removed |Added
CC||kyrylo.tkachov at arm dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66902
--- Comment #6 from Jonathan Wakely ---
3.5 [basic.link]:
-3- A name having namespace scope (3.3.6) has internal linkage if it is the
name of
— a variable, function or function template that is explicitly declared
static; or,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67546
Kai Tietz changed:
What|Removed |Added
Target|x86_64-w64-mingw32 |*-*-mingw32
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67546
--- Comment #3 from Kai Tietz ---
Thanks Rainer for pointing on this. Yes, comment wasn't intended for this bug.
I added comment to proper pr ...
This issue is related to the fact that msvcrt doesn't provide unsetenv (as it
doesn't provide set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67141
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67546
--- Comment #2 from Rainer Emrich ---
(In reply to Kai Tietz from comment #1)
> I added to mingw-w64's libwinpthread a work-a-round for this sloopy code in
> libgomp. Nevertheless issue should be fixed IMO in libgomp, too
Wrong PR, this belongs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66902
--- Comment #5 from Vadim Zhukov ---
(In reply to Jonathan Wakely from comment #4)
> Author: redi
> Date: Thu Sep 3 19:05:15 2015
> New Revision: 227466
>
> URL: https://gcc.gnu.org/viewcvs?rev=227466&root=gcc&view=rev
> Log:
> PR libstdc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65092
--- Comment #3 from Jonathan Wakely ---
Author: redi
Date: Fri Sep 11 09:51:29 2015
New Revision: 227680
URL: https://gcc.gnu.org/viewcvs?rev=227680&root=gcc&view=rev
Log:
Allocator-extended constructors for container adaptors.
PR libst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65092
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67506
--- Comment #9 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #6)
> Thanks. I will commit it and add attachment 36309 [details] as a c-torture
> test.
Thanks for the quick bug fix! Matthias already uploaded a new gcc-5 s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304
--- Comment #24 from Ramana Radhakrishnan ---
Author: ramana
Date: Fri Sep 11 09:44:26 2015
New Revision: 227679
URL: https://gcc.gnu.org/viewcvs?rev=227679&root=gcc&view=rev
Log:
Remove separate movtf pattern - Use an iterator for all FP modes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
Manfred Schwarb changed:
What|Removed |Added
CC||manfred99 at gmx dot ch
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67546
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67535
--- Comment #6 from Vittorio Zecca ---
The cost of adding "if(base_name_len)" is two x86-64 machine instructions
cmpl$0, -20(%rbp)
je .L2
Six instructions follow then
call memcpy
which is not exactly a NOP eve
91 matches
Mail list logo
