https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87762
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2018-10-26
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87762
Bug ID: 87762
Summary: extract_constrain_insn, at recog.c:2206 on s390x
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #46 from Douglas Mencken ---
(In reply to Wilco from comment #38)
> You can have data in text sections, including bytes and half words. Even if
> instructions aligned automatically, the function label might be unaligned if
> it was p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #45 from Douglas Mencken ---
(In reply to self from comment #44)
> I can’t get where is the value of STACK_DYNAMIC_OFFSET in published assembly
> and why do you think it is wrong
Most likely this value is shown as 96 in “addi r1,r30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #44 from Douglas Mencken ---
I got assembly of pr78468.c from various versions of GCC
• 7.3 produces absolutely the same as patched 8.2
• 6.4 produces slightly different assembly with stmw & lmw and different
sequence of instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87761
Bug ID: 87761
Summary: [9 regression][MIPS] New FAIL:
gcc.target/mips/fix-r4000-10.c -O1 start with
r265398
Product: gcc
Version: 9.0
Status: UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85860
--- Comment #4 from Zdenek Sojka ---
Created attachment 44904
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44904&action=edit
unreduced testcase
(In reply to Arseny Solokha from comment #3)
> I cannot reproduce it anymore w/ gcc-9.0.0-alp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83173
--- Comment #8 from Eric Gallager ---
(In reply to Pádraig Brady from comment #7)
> Have been running with these patches on an extremely large code base for the
> last few months, without issue
Can you say which code base?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85860
--- Comment #3 from Arseny Solokha ---
I cannot reproduce it anymore w/ gcc-9.0.0-alpha20181021 snapshot (r265361).
Seems to be fixed on the trunk w/ recent LRA-related patches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21161
Eric Gallager changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #18 from Eric Galla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82738
Bug 82738 depends on bug 68836, which changed state.
Bug 68836 Summary: GCC can't properly emit debug info for function arguments in
a back-trace when using -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68836
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68836
Eric Gallager changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28036
--- Comment #7 from Eric Gallager ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Eric Gallager from comment #4)
> > Seeing as this bug is about how libffi is used by gcj, and gcj has been
> > removed from gcc, does it still need t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87760
Bug ID: 87760
Summary: Unable to delete overloads of std::memset on arm
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87759
Bug ID: 87759
Summary: [8/9 Regression] ICE in lra_assign, at
lra-assigns.c:1624, or ICE: Maximum number of LRA
assignment passes is achieved (30), or compile-time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #7 from Arthur O'Dwyer ---
> std::string is not trivially relocatable in libstdc++
This is surprising news to me! Just goes to show that we would benefit from an
accurate detection mechanism and type trait. :)
> so I won't waste any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87758
Bug ID: 87758
Summary: --print-file-name= ignores -L
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #43 from Wilco ---
(In reply to Douglas Mencken from comment #42)
> (In reply to Wilco from comment #41)
>
> > So what is the disassembly now?
>
> $ /Developer/GCC/8.2p/PowerPC/32bit/bin/gcc -O2 -fno-inline pr78468.c
> -save-temps
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #42 from Douglas Mencken ---
(In reply to Wilco from comment #41)
> So what is the disassembly now?
$ /Developer/GCC/8.2p/PowerPC/32bit/bin/gcc -O2 -fno-inline pr78468.c
-save-temps
$ mv pr78468.s ~/
$ diff -u ~/8.2patched-pr78468.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #41 from Wilco ---
(In reply to Douglas Mencken from comment #40)
> To build it, I patched its sources with fix_gcc8_build.patch reversion
> together with changes from comment #16
So what is the disassembly now? The 2nd diff still s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #40 from Douglas Mencken ---
Yet I got what I wanted ~ the working GCC 8.2
$ /Developer/GCC/8.2p/PowerPC/32bit/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/Developer/GCC/8.2p/PowerPC/32bit/bin/gcc
COLLECT_LTO_WRAPPER=/Developer/GCC/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #39 from Douglas Mencken ---
(In reply to Wilco from comment #38)
> You can have data in text sections, including bytes and half words. Even if
> instructions aligned automatically, the function label might be unaligned if
> it was p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #38 from Wilco ---
(In reply to Douglas Mencken from comment #37)
> And some more in my wish list. May GCC don’t generate these
>
> .align2
>
> in text section? Any, each and every powerpc instruction is 32bit-wide, no
> and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #37 from Douglas Mencken ---
And some more in my wish list. May GCC don’t generate these
.align 2
in text section? Any, each and every powerpc instruction is 32bit-wide, no and
never more, no and never less, so these aligns are red
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #36 from Douglas Mencken ---
(In reply to Iain Sandoe from comment #31)
> * please could you use
> --build=powerpc-apple-darwin9 --host=powerpc-apple-darwin9
> --target=powerpc-apple-darwin9 (or leave these off - which will cause it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #35 from Douglas Mencken ---
(In reply to Wilco from comment #33)
> So functions must preserve 16-byte alignment, but can they rely on the stack
> being always 16-byte aligned on entry?
I bet yes when it’s not some hardcoded-by-hand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #34 from Douglas Mencken ---
Created attachment 44903
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44903&action=edit
8.2vanilla-pr78468.s
And there’s assembly produced by *vanilla* (id est with Wilco’s r251713 causing
the fai
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87757
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #33 from Wilco ---
(In reply to Iain Sandoe from comment #30)
> From "Mac_OS_X_ABI_Function_Calls.pdf"
>
> m32 calling convention
>
> Prologs and Epilogs
> The called function is responsible for allocating its own stack frame,
> ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87757
Bug ID: 87757
Summary: weird underlining and colors in sprintf warnings for
unterminated arrays
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #32 from Wilco ---
(In reply to Segher Boessenkool from comment #29)
> It aligns the stack to 16:
>
> # r3 is size, at entry
> addi r3,r3,18
> ...
> rlwinm r3,r3,0,0,27
> ...
> neg r3,r3
> ..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87756
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87756
Bug ID: 87756
Summary: missing unterminated argument warning using address of
a constant character
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87742
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #31 from Iain Sandoe ---
(In reply to Douglas Mencken from comment #4)
> (In reply to Richard Biener from comment #3)
> > How did you configure?
>
> As always
>
> ../gcc-8.1.0/configure \
> --build=powerpc-unknown-darwin --host=powe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #30 from Iain Sandoe ---
(In reply to Segher Boessenkool from comment #27)
> The stack is always 16B-aligned on Darwin as far as I know. Cc:ing Iain, he
> will know for sure (I cannot find the docs, &^%*&^$#*&%)
I actually thought w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #29 from Segher Boessenkool ---
It aligns the stack to 16:
# r3 is size, at entry
addi r3,r3,18
...
rlwinm r3,r3,0,0,27
...
neg r3,r3
...
lwz r2,0(r1)
...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87709
--- Comment #4 from Baruch Burstein ---
There is a pretty good (speculative) analysis of this issue here:
https://stackoverflow.com/a/52986284/331785
I am copying it to here for completeness, but credit for this goes to the
author of that post:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52994
--- Comment #13 from Dominique d'Humieres ---
> FYI : On my environment it's not possible to produce an ICE with gcc-9
> and several tested combinations of options / all tested configurations.
>
> $ gfortran-9-20181021 -c pr52994.f90
> pr52994.f9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #28 from Douglas Mencken ---
Created attachment 44902
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44902&action=edit
8.2patched-pr78468.s
Assembly produced by patched 8.2’s stage1 xgcc compiled using
prev-gcc/xgcc -B/Volumes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
Segher Boessenkool changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #26 from Wilco ---
(In reply to Douglas Mencken from comment #25)
> (In reply to Wilco from comment #24)
>
> > Yes the stage1 compiler would be fine or alternatively use
> > --disable-bootstrap to get an installed compiler.
>
> I’m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #25 from Douglas Mencken ---
(In reply to Wilco from comment #24)
> Yes the stage1 compiler would be fine or alternatively use
> --disable-bootstrap to get an installed compiler.
I’m yet at libstdc++ of stage2 (which means that it s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #24 from Wilco ---
(In reply to Douglas Mencken from comment #22)
> (In reply to Wilco from comment #21)
>
> > That's odd. The stack pointer is definitely 16-byte aligned in all cases
> > right?
>
> As I know, PowerPC has no specia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #23 from Douglas Mencken ---
Created attachment 44901
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44901&action=edit
fix_gcc8_build.patch
Reversion of r251713, updated for patching sources of 8.2 release
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87755
--- Comment #1 from seurer at gcc dot gnu.org ---
Note: This happens during a make check.
This may be more of the error output:
ERROR: tcl error sourcing
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/lto/lto.exp.
ERROR: couldn't compile regula
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #22 from Douglas Mencken ---
(In reply to Wilco from comment #21)
> That's odd. The stack pointer is definitely 16-byte aligned in all cases
> right?
As I know, PowerPC has no special “stack pointer”, it is just one of general
purp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87754
Rainer Orth changed:
What|Removed |Added
Target|i386-pc-solaris2.11,|i386-pc-solaris2.11,
|sp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
Wilco changed:
What|Removed |Added
CC||wdijkstr at arm dot com
--- Comment #21 from Wil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #20 from Segher Boessenkool ---
This is
#define SUPPORTS_STACK_ALIGNMENT (MAX_STACK_ALIGNMENT > STACK_BOUNDARY)
and
#define MAX_STACK_ALIGNMENT STACK_BOUNDARY
so that seems normal.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #19 from Douglas Mencken ---
I dunno are such warnings related or not
echo timestamp > s-gtype
ccache /Developer/GCC/7.3p/PowerPC/32bit/bin/g++ -std=gnu++98 -fno-PIE -c -g
-mdynamic-no-pic -DIN_GCC -fno-exceptions -fno-rtti
-fa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87755
Bug ID: 87755
Summary: [9 regression] ERROR: couldn't compile regular
expression pattern: quantifier operand invalid
Product: gcc
Version: 9.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #18 from Douglas Mencken ---
(In reply to Wilco from comment #17)
> Yes that should work.
Oops, but it doesn’t. I just tested it with patched 8.2. Same messages, same
breakage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87754
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |9.0
Between 20181024 (r265465) and 20181025 (r265498), the following error occured
on Solaris 11/x86 and SPARC, both 32 and 64-bit:
+ERROR: couldn't compile regular expression pattern: quantifier operand invalid
+ERROR: tcl error sourcing
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/lto/lto.exp.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86837
Dominique d'Humieres changed:
What|Removed |Added
CC||hvandam at bnl dot gov
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87753
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87753
--- Comment #1 from Hubertus van Dam ---
Created attachment 44900
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44900&action=edit
The data file that the program reads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87753
Bug ID: 87753
Summary: READ statement with nested implied do broken with
optimization
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #6 from Marc Glisse ---
Re-reading P1144R0 (those are not necessarily comments on the paper, just what
comes to mind for gcc):
1) yes, an automatic detection mechanism would be nice, and an attribute makes
sense.
2) the conditionally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #17 from Wilco ---
(In reply to Douglas Mencken from comment #16)
> Like this?
>
> --- a/gcc/config/rs6000/darwin.h
> +++ b/gcc/config/rs6000/darwin.h
> @@ -150,13 +150,12 @@
>
> #undef RS6000_STARTING_FRAME_OFFSET
> #define RS60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52994
G. Steinmetz changed:
What|Removed |Added
CC||gs...@t-online.de
--- Comment #12 from G.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #16 from Douglas Mencken ---
Like this?
--- a/gcc/config/rs6000/darwin.h
+++ b/gcc/config/rs6000/darwin.h
@@ -150,13 +150,12 @@
#undef RS6000_STARTING_FRAME_OFFSET
#define RS6000_STARTING_FRAME_OFFSET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87752
--- Comment #1 from G. Steinmetz ---
Compiles without "simd" :
$ cat z2.f90
subroutine foo (n, u, v)
integer :: n
real, pointer :: u(:), v(:)
!$omp parallel do
do i = 1, n
u(:) = v(:)
end do
end
$ gfortran -9-20181021 -c z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87752
Bug ID: 87752
Summary: ICE in omp_add_variable, at gimplify.c:6776
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87704
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87749
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87751
Bug ID: 87751
Summary: ICE in gfc_trans_assignment_1, at
fortran/trans-expr.c:10255
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87749
--- Comment #4 from Jonathan Wakely ---
Author: redi
Date: Thu Oct 25 16:42:01 2018
New Revision: 265500
URL: https://gcc.gnu.org/viewcvs?rev=265500&root=gcc&view=rev
Log:
PR libstdc++/87749 fix (and optimize) string move construction
The move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87704
--- Comment #5 from Jonathan Wakely ---
Author: redi
Date: Thu Oct 25 16:41:54 2018
New Revision: 265499
URL: https://gcc.gnu.org/viewcvs?rev=265499&root=gcc&view=rev
Log:
PR libstdc++/87704 fix unique_ptr(nullptr_t) constructors
Using a delega
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71196
--- Comment #5 from G. Steinmetz ---
Looking at variations z1..z4 with two data statements
and combinations z5..z8 with one data statement only :
# cat z1.f90
# ICE, see comment above
$ cat z2.f90
program p
type t
character(3) :: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71196
G. Steinmetz changed:
What|Removed |Added
CC||gs...@t-online.de
--- Comment #4 from G.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #5 from Marc Glisse ---
(In reply to Arthur O'Dwyer from comment #4)
> Have you seen my libc++ patch on the same topic as yours?
>
> https://quuxplusone.github.io/blog/2018/07/18/announcing-trivially-
> relocatable/
> https://github.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87749
--- Comment #3 from Jonathan Wakely ---
Author: redi
Date: Thu Oct 25 16:32:47 2018
New Revision: 265497
URL: https://gcc.gnu.org/viewcvs?rev=265497&root=gcc&view=rev
Log:
PR libstdc++/87749 fix (and optimize) string move construction
The move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87749
--- Comment #2 from Jonathan Wakely ---
Author: redi
Date: Thu Oct 25 16:21:19 2018
New Revision: 265496
URL: https://gcc.gnu.org/viewcvs?rev=265496&root=gcc&view=rev
Log:
PR libstdc++/87749 fix (and optimize) string move construction
The move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87750
Bug ID: 87750
Summary: Failed compilation / parsing of template member call
after 'using' declaration
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87723
--- Comment #2 from Andreas Krebbel ---
(In reply to Andreas Krebbel from comment #1)
> Created attachment 44898 [details]
> Patch
>
> The "*rsbg_di_rotl" output string uses mode attributes with actually
> using a mode iterator.
s/with/without/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87723
--- Comment #1 from Andreas Krebbel ---
Created attachment 44898
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44898&action=edit
Patch
The "*rsbg_di_rotl" output string uses mode attributes with actually
using a mode iterator.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87739
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87739
--- Comment #4 from Martin Liška ---
Author: marxin
Date: Thu Oct 25 15:36:48 2018
New Revision: 265495
URL: https://gcc.gnu.org/viewcvs?rev=265495&root=gcc&view=rev
Log:
Use signed char in a test (PR testsuite/87739).
2018-10-25 Martin Liska
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87735
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87735
--- Comment #4 from Martin Liška ---
Author: marxin
Date: Thu Oct 25 15:36:12 2018
New Revision: 265494
URL: https://gcc.gnu.org/viewcvs?rev=265494&root=gcc&view=rev
Log:
Revert partially changes from r265454 (PR other/87735).
2018-10-25 Marti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87749
--- Comment #1 from Jonathan Wakely ---
Author: redi
Date: Thu Oct 25 15:34:04 2018
New Revision: 265493
URL: https://gcc.gnu.org/viewcvs?rev=265493&root=gcc&view=rev
Log:
PR libstdc++/87749 fix (and optimize) string move construction
The move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #15 from Wilco ---
> This will correctly align the outgoing arguments to fails to align the
> outgoing arguments. The STACK_DYNAMIC_OFFSET definitions in rs6000.h and
> aix.h are correct.
Note RS6000_STARTING_FRAME_OFFSET also needs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87723
Andreas Krebbel changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|2018-10-24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86907
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #14 from Wilco ---
Since DEFAULT_ABI == ABI_DARWIN, the save area is 24 bytes:
#define RS6000_SAVE_AREA \
((DEFAULT_ABI == ABI_V4 ? 8 : DEFAULT_ABI == ABI_ELFv2 ? 16 : 24) \
<< (TARGET_64BIT ? 1 : 0))
STACK_BOUNDARY is 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86907
--- Comment #6 from Jürgen Reuter ---
Indeed, with --enable-checking=release on MACOSX and default option (which is
--enable-checking=yes) if I understand it correctly, the warning seems not to
be present. I didn't test --enable-checking=yes on M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86158
Martin Liška changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86158
--- Comment #10 from seurer at gcc dot gnu.org ---
For a while the test case stopped failing (I don't know why but from the
results logs it was about 25 June this year around r262009) but just recently
it started again (sometime around r264987 on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #13 from Douglas Mencken ---
Current repo which HEAD is
commit b75be89021ca1da066f892d9a26329009432654c
Author: meissner
Date: Wed Oct 24 20:16:31 2018 +
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@265471
138bc75d-0d04-04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #12 from Douglas Mencken ---
I finished it
git bisect start
git bisect good gcc-7_3_0-release # r257041
git bisect bad gcc-8_1_0-release # r259829
git bisect good 7369309777f6d6e630fb7763bcd08a0317727e36 # r247015 merge parent
git bi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87747
--- Comment #3 from iii at gcc dot gnu.org ---
Author: iii
Date: Thu Oct 25 13:47:10 2018
New Revision: 265488
URL: https://gcc.gnu.org/viewcvs?rev=265488&root=gcc&view=rev
Log:
Fix rtx_code_size static initialization order fiasco
r264556 and r2
on/87665
PR tree-optimization/87745
* tree-vectorizer.h (get_earlier_stmt): Remove.
(get_later_stmt): Pick up UID from the original non-pattern stmt.
* gfortran.dg/20181025-1.f: New testcase.
Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/20181025-1.f
on/87665
PR tree-optimization/87745
* tree-vectorizer.h (get_earlier_stmt): Remove.
(get_later_stmt): Pick up UID from the original non-pattern stmt.
* gfortran.dg/20181025-1.f: New testcase.
Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/20181025-1.f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87747
--- Comment #2 from Ilya Leoshkevich ---
This is a little bit more complicated, because EQ_ATTR_ALT is valid only for
GENERATOR_FILEs. The regtest has just finished, so I will post the patch to
the mailing list now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #3 from Marc Glisse ---
Author: glisse
Date: Thu Oct 25 13:03:13 2018
New Revision: 265485
URL: https://gcc.gnu.org/viewcvs?rev=265485&root=gcc&view=rev
Log:
Relocation (= move+destroy)
2018-10-25 Marc Glisse
PR libstdc+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87255
--- Comment #2 from Jakub Jelinek ---
I'm aware of this, but fixing it without actually penalizing performance won't
be very easy. Have been also waiting on what will be voted into OpenMP 5.0
here, in the end it says that the expressions are to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87255
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
1 - 100 of 158 matches
Mail list logo
