Delayed slot filling moves insns without any regard to variable
location notes, causing the location information in them to become
incorrect.
Fixing that appears to be quite difficult, but filling delay slots is
hardly an essential optimization to run at -Og, so if the user wants
to privilege
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.
Hi,
This is a rebased version of patch that adds a pattern to neon.md for
implementing division with multiplication by reciprocal using
vrecpe/vrecps with -funsafe-math-optimizations excluding -Os.
The newly added test-cases are not vectorized on armeb target with
-O2. I posted the analysis for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21161
Eric Gallager changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #18 from Eric
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
This patch introduces a couple of compiler tests for the OpenACC
attach and detach clauses.
Is this OK for trunk after the other patches get approved?
Thanks,
Cesar
2018-XX-YY Cesar Philippidis
gcc/testsuite/
* c-c++-common/goacc/mdc-1.c: New test.
* c-c++-common/goacc/mdc-2.c: New test.
This patch adds support for attach and detach in the C front end. All
of the comments for the C FE patch apply here. Arguably, there's not a
significant difference between cp_oacc_check_attachments and its C
counterpart. However, I decided to keep them separate in case the
standard gets updated in
This patch adds support for attach and detach in the C front end. Both
attach and detach are a little different from the other data clauses
because they require variables that are pointers. Consequently, this
patch teaches handle_omp_array_sections_1 to bail out of it detects a
subarray argument
This patch series adds support for the new attach / detach clauses
introduced in OpenACC 2.6 to the C and C++ front ends. Julian is
working patches for the Fortran front end along with the runtime.
As their names somewhat imply, attach and detach are new data clauses
that are used to support
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
On 10/25/18 4:33 PM, Kugan Vivekanandarajah wrote:
> Hi,
>
> PR87528 showed a case where libgcc generated popcount is causing
> regression for Skylake.
> We also have PR86677 where kernel build is failing because the kernel
> does not use the libgcc (when backend is not defining popcount
>
On 10/25/18 4:44 PM, Kugan Vivekanandarajah wrote:
> Hi,
>
> This patch adds some of the missing patterns in match.pd for ABSU_EXPR
> and it is a revised version based on the review at
> https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00046.html
> Bootstrapped and regression tested on
The last patch to libgo added a use of wc to the gotest script.
However, wc is not in the GNU approved list of Makefile utilities
(https://www.gnu.org/prep/standards/html_node/Utilities-in-Makefiles.html#Utilities-in-Makefiles).
So replace it by sed. Bootstrapped and ran Go testsuite on
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
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
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
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
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
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
>
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
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
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=edit
8.2vanilla-pr78468.s
And there’s assembly produced by *vanilla* (id est with Wilco’s r251713 causing
the fail in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87757
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
CC|
In my target (pdp11) which has 16 bit words, I see some test suite failures
because of unresolved references to __cmpsi2. The strange thing is that most
of the time 32 bit compares are expanded by GCC into a sequence of word
compares and branches.
Why would GCC sometimes generate library
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,
>
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
>
On 26/10/18 00:17 +0100, Jonathan Wakely wrote:
On 26/10/18 00:42 +0200, Marc Glisse wrote:
On Fri, 26 Oct 2018, Ville Voutilainen wrote:
I would rather not introduce a behavioral difference between us and
libc++.
Why not? There are already several, and it helps find bugs. Maybe
you could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87756
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87742
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
On 26/10/18 00:42 +0200, Marc Glisse wrote:
On Fri, 26 Oct 2018, Ville Voutilainen wrote:
I would rather not introduce a behavioral difference between us and
libc++.
Why not? There are already several, and it helps find bugs. Maybe you
could convince libc++ to change as well if you want to
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
I've taken the advice from a discussion on IRC and re-wrote the patch
with more uniform function names and using overloading.
I think this function accomplished the following goals:
- remove clone numbering where it's not needed:
final.c:final_scan_insn_1 and
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
Hi,
This patch adds some of the missing patterns in match.pd for ABSU_EXPR
and it is a revised version based on the review at
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00046.html
Bootstrapped and regression tested on x86_64-linux-gnu with no new
regressions. Is this OK trunk?
Thanks,
Kugan
On Fri, 26 Oct 2018, Ville Voutilainen wrote:
I would rather not introduce a behavioral difference between us and
libc++.
Why not? There are already several, and it helps find bugs. Maybe you
could convince libc++ to change as well if you want to keep the behavior
the same?
It does
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)
...
Snapshot gcc-7-20181025 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/7-20181025/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7
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:
On Thu, 25 Oct 2018, Jonathan Wakely wrote:
When an SSO string is contained in the small string buffer or has an
unequal allocator a move operation performs a copy, leaving the original
data in the moved-from string. Setting the length of the moved-from
string to zero is not required, so we can
Hi,
PR87528 showed a case where libgcc generated popcount is causing
regression for Skylake.
We also have PR86677 where kernel build is failing because the kernel
does not use the libgcc (when backend is not defining popcount
pattern). While I agree that the kernel should implement its own
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
>
On Thu, Oct 25, 2018 at 02:07:45PM -0500, Paul Clarke wrote:
> Enable 32bit support for tests of x86-compatibile intrinsics
>
> Bootstrapped and tested on Linux POWER8 LE, POWER8 BE (64 & 32), and POWER7.
>
> OK for trunk?
This is fine when the previous patch is in as well. Thanks!
>
On Thu, Oct 25, 2018 at 02:07:33PM -0500, Paul Clarke wrote:
> Various clean-ups for 32bit support.
>
> Implement various corrections in the compatibility implementations of the
> x86 vector intrinsics found after enabling 32bit mode for the associated
> test cases. (Actual enablement coming in
This patch by Than McIntosh improves the mangling of package paths in
the Go frontend.
The current implementation of Gogo::pkgpath_for_symbol was written in
a way that allowed two distinct package paths to map to the same
symbol, which could cause collisions at link- time or compile-time.
This
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=edit
8.2patched-pr78468.s
Assembly produced by patched 8.2’s stage1 xgcc compiled using
prev-gcc/xgcc
On Thu, Oct 25, 2018 at 05:07:03PM -0500, Segher Boessenkool wrote:
> On Thu, Oct 25, 2018 at 01:41:15PM -0500, Paul Clarke wrote:
> > For compatibility implementation of x86 vector intrinsic, _mm_extract_pi16,
> > adjust shift value for big-endian mode.
> >
> > Bootstrapped and tested on Linux
On Thu, Oct 25, 2018 at 01:41:15PM -0500, Paul Clarke wrote:
> For compatibility implementation of x86 vector intrinsic, _mm_extract_pi16,
> adjust shift value for big-endian mode.
>
> Bootstrapped and tested on Linux POWER8 LE, POWER8 BE (64 & 32), and POWER7.
Does it fix existing testcases?
On Fri, 26 Oct 2018 at 00:54, Jonathan Wakely wrote:
>
> When an SSO string is contained in the small string buffer or has an
> unequal allocator a move operation performs a copy, leaving the original
> data in the moved-from string. Setting the length of the moved-from
> string to zero is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
Segher Boessenkool changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
---
When an SSO string is contained in the small string buffer or has an
unequal allocator a move operation performs a copy, leaving the original
data in the moved-from string. Setting the length of the moved-from
string to zero is not required, so we can avoid two writes (to the
length member and to
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
I have a question about process_bb_lives and check_pseudos_live_through_calls.
I am trying to optimize aarch64 vector functions, which do not partially
clobber vector registers the way that 'normal' functions do. To do this
I am looking at modifying the hard_regno_call_part_clobbered target
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
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
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=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
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
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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
Wilco changed:
What|Removed |Added
CC||wdijkstr at arm dot com
--- Comment #21 from
On 10/25/18 2:15 AM, Rainer Orth wrote:
> Hi Jeff,
>
>> On 10/24/18 7:06 AM, Rainer Orth wrote:
>>> Between 20181022 (r265393) and 20181023 (r265430), gcc.dg/pr78973-2.c
>>> began to XPASS on a large number of targets:
>>>
>>> +XPASS: gcc.dg/pr78973-2.c ilp32 (test for warnings, line 16)
>>>
>>>
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.
Hi,
A number of the test cases for the intrinsic compatibility headers are set up
to dump more information when a test case fails and the DEBUG macro has been
set. Unfortunately, many of them also then pass the test case since they no
longer call abort(). This patch fixes that oversight (or
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
On Wed, Oct 24, 2018 at 07:55:44PM -0500, Bill Schmidt wrote:
> The intrinsic compatibility headers make use of some deprecated functions for
> vector shifts, which are not available in some compilers. For compatibility
> reasons, this patch, replaces those with intrinsics guaranteed to be
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
Whee, this was fun to debug...
The lr78 port is crippled enough that it has to have its own specialized
register allocation phase. Essentially all insns have two
implementations, one is virtual and used up through the target specific
register allocation pass and a physical implementation used
The call in cp_parser_sizeof_operand is also redundant.
Tested x86_64-pc-linux-gnu, applying to trunk.
---
gcc/cp/parser.c | 15 +--
gcc/cp/ChangeLog | 5 +
2 files changed, 6 insertions(+), 14 deletions(-)
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index
Hi Carl,
On Wed, Oct 24, 2018 at 12:44:23PM -0700, Carl Love wrote:
> The scalar_cmp_exp_eq, scalar_cmp_lt, scalar_cmp_gt,
> scalar_cmp_unordered are missing support for the _ieee128 arguments.
> This patch adds the missing support and a test file for the builtins
> for both _ieee128 and double
On 9/3/18 7:50 PM, Julian Brown wrote:
On Fri, 31 Aug 2018 16:20:08 +0200
Jakub Jelinek wrote:
On Fri, Aug 31, 2018 at 10:04:07AM -0400, Nathan Sidwell wrote:
On 08/30/2018 04:27 PM, Jason Merrill wrote:
On Thu, Aug 30, 2018 at 3:31 PM, Julian Brown
wrote:
"Apart from parsing, it's
On 10/12/18 9:32 AM, Andrew Sutton wrote:
BTW, I would discourage you from messing much with the concepts code
at this point, as a major overhaul should be coming soon.
Major overhaul:
https://github.com/asutton/gcc (branch is concepts; we're about 2 weeks
back from trunk).
Awesome!
This is part 2/2 for contributing PPC64LE support for X86 SSE3
instrisics. This patch includes testsuite/gcc.target tests for the
intrinsics defined in pmmintrin.h, copied from gcc.target/i386.
Bootstrapped and tested on Linux POWER8 LE, POWER8 BE (64 & 32), and POWER7.
OK for trunk?
This is a follow-on to earlier commits for adding compatibility
implementations of x86 intrinsics for PPC64LE. This is the first of
two patches for SSSE3. This patch adds the 32 x86 intrinsics from
("SSSE3"). (Patch 2/2 adds tests for these intrinsics,
and briefly describes the tests
Various clean-ups for 32bit support.
Implement various corrections in the compatibility implementations of the
x86 vector intrinsics found after enabling 32bit mode for the associated
test cases. (Actual enablement coming in a subsequent patch.)
Bootstrapped and tested on Linux POWER8 LE,
I ran into a failures due to no weak symbol support in my target. This patch
cures that. Is it right? The test case uses "weakref" so I' not 100% sure
that checking for "weak" support is correct. If not, I can put in a skip-if
check for the target (pdp11) instead.
paul
ChangeLog:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86837
Dominique d'Humieres changed:
What|Removed |Added
CC||hvandam at bnl dot gov
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87753
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
On Thu, Oct 25, 2018 at 7:12 AM Umesh Kalappa wrote:
>
> Hi All,
>
> For the below C code
>
> Test.u32pt = u32PtLen;
> Test.u32pn = u32PtCnt;
> Test.pstpk = pstPt;
> Test.psteo = pstEgrInfo;
> Test.e = 1;
> Test.pstfi = pstFi ;
>
> return foo(, AclAction);
>
>
Hi!
In OpenMP 5.0 missing schedule modifier implies nonmonotonic unless it is
static or ordered clause is present (that has been committed already
earlier), but also the nonmonotonic modifier is allowed on static, runtime
and auto schedules and run-sched-var ICV now includes a monotonic modifier
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=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
For compatibility implementation of x86 vector intrinsic, _mm_extract_pi16,
adjust shift value for big-endian mode.
Bootstrapped and tested on Linux POWER8 LE, POWER8 BE (64 & 32), and POWER7.
OK for trunk?
gcc/ChangeLog:
2018-10-25 Paul A. Clarke
* config/rs6000/xmmintrin.h: Fix
While testing the optimize and target attributes and comparing
the results to what the manual describes I noticed that some
syntactic forms aren't fully documented for both attributes.
Specifically, the optimize attribute doesn't mention that each
string argument can be a comma-separated list
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
On 10/8/18 6:24 PM, David Malcolm wrote:
On Mon, 2018-10-08 at 10:37 -0400, Jason Merrill wrote:
On Thu, Oct 4, 2018 at 10:12 AM David Malcolm
wrote:
-Wformat in the C++ FE doesn't work as well as it could:
(a) it doesn't report precise locations within the string literal,
and
(b) it doesn't
On 10/11/18 8:07 PM, David Malcolm wrote:
On Thu, 2018-10-11 at 10:31 -0400, Jason Merrill wrote:
On Thu, Oct 11, 2018 at 10:28 AM Jason Merrill
wrote:
On Wed, Oct 10, 2018 at 5:01 PM David Malcolm
wrote:
On Tue, 2018-10-09 at 18:38 -0400, Jason Merrill wrote:
On Tue, Oct 9, 2018 at 1:19
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
On 10/25/18 12:08 PM, Segher Boessenkool wrote:
> On Wed, Oct 24, 2018 at 09:25:25AM -0500, Bill Schmidt wrote:
>> This patch addresses Segher's findings, and also replaces usages of the
>> deprecated function vec_vcmpgtfp with the equivalent vec_cmpgt.
>> Bootstrapped and tested on
Hi!
On Wed, Oct 24, 2018 at 02:30:10PM -0500, Bill Schmidt wrote:
> Due to some unfortunate history, not all compilers currently have correct
> result
> types produced for comparison operators on vector types. For compatibility
> purposes, this patch replaces those with vec_cmp* built-ins. It
1 - 100 of 259 matches
Mail list logo
