https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79241
--- Comment #5 from night_ghost at ykoctpa dot ru ---
I'll try to exclude maximum of unneeded code from testcase and then upload it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79254
--- Comment #7 from Daryl Haresign ---
I would also be inclined to reverse your Guard: have it take 'this', have an
'activate' method which swaps in the new values, have a 'deactivate' method
which releases the memory, and have its destructor swa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79254
--- Comment #6 from Daryl Haresign ---
I guess you don't want _M_copy_assign to be public, either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79254
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79254
Jonathan Wakely changed:
What|Removed |Added
Known to work||4.9.4
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79254
--- Comment #3 from Jonathan Wakely ---
That patch is wrong, it also needs this in the catch block to restore the
original allocator:
_M_get_allocator() = __guard._M_alloc;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79254
--- Comment #2 from Jonathan Wakely ---
Created attachment 40604
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40604&action=edit
Untested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79254
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602
--- Comment #18 from Martin Sebor ---
I don't know the full history behind this particular warning but I think a good
way to find out if it can be adopted by GCC is to see the extent of the changes
required to clean up the code base so it compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71433
--- Comment #12 from Vincent Lefèvre ---
New test case, based on the previous one (just a __builtin_expect added):
int t[1];
int a (void);
int fct (int r, long e, int neg)
{
int d = 0;
if (r == 4)
r = neg ? 3 : 2;
if (__builtin_expect(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79211
--- Comment #1 from Segher Boessenkool ---
I cannot reproduce this problem; are there any special (configure)
flags I need?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71433
Vincent Lefèvre changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602
--- Comment #17 from Manuel López-Ibáñez ---
(In reply to Martin Sebor from comment #16)
> There are straightforward ways to avoid interspersing code with preprocessor
> conditionals:
Will GCC adopt this approach so that the warning can be enabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79254
Bug ID: 79254
Summary: basic_string::operator= isn't exception safe
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79216
--- Comment #10 from H. Peter Anvin ---
It is not. I guess I'd like to modify the request to allow
__attribute__((scalar_storage_order())) to be specified for scalar *pointer*.
That would bring the 90% up to 99% at the very least; the inability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79217
--- Comment #5 from H. Peter Anvin ---
As noted on bug 79219 there are a few issues with simply relying on __int128,
even if 32 bits is the natural "limb" size on a 32-bit architecture.
a) it requires algorithms to be implemented using lengthy (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79219
--- Comment #8 from H. Peter Anvin ---
(In reply to Richard Biener from comment #1)
> So you mean DW/W -> W, but that can result in the result being not
> representable?
> What's the desired behavior in this case? Invoking undefined behavior?
W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79219
--- Comment #7 from H. Peter Anvin ---
Created attachment 40603
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40603&action=edit
Test case: assembly output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79219
--- Comment #6 from H. Peter Anvin ---
Created attachment 40602
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40602&action=edit
Test case: preprocessor output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79219
--- Comment #5 from H. Peter Anvin ---
Created attachment 40601
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40601&action=edit
Test case: source code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79217
--- Comment #4 from H. Peter Anvin ---
My apologies for the three attachments; I incorrectly attached them to the
wrong bug report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79216
--- Comment #9 from Eric Botcazou ---
> I guess I'm confused why it would not be possible to specify the endianness
> of a scalar, or perhaps far more importantly a pointer to a scalar. Other
> than that, this feature seems to do 90% of what I w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79217
--- Comment #3 from H. Peter Anvin ---
Created attachment 40600
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40600&action=edit
Assembly output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79217
--- Comment #2 from H. Peter Anvin ---
Created attachment 40599
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40599&action=edit
Preprocessor output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79217
--- Comment #1 from H. Peter Anvin ---
Created attachment 40598
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40598&action=edit
Source code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79219
--- Comment #4 from H. Peter Anvin ---
There are a few issues with that:
a) the overflow behavior is inherently different, which is why the inline you
propose doesn't work. Try compiling the attached program, on x86-64 it
produces a call to __u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #23 from Eric Botcazou ---
Created attachment 40597
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40597&action=edit
Tentative fix I'm going to test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79216
--- Comment #8 from H. Peter Anvin ---
I guess I'm confused why it would not be possible to specify the endianness of
a scalar, or perhaps far more importantly a pointer to a scalar. Other than
that, this feature seems to do 90% of what I was as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78703
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78703
--- Comment #10 from Martin Sebor ---
Author: msebor
Date: Thu Jan 26 23:07:02 2017
New Revision: 244956
URL: https://gcc.gnu.org/viewcvs?rev=244956&root=gcc&view=rev
Log:
PR middle-end/78703 - fprintf-return-value floating point handling incorr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79210
--- Comment #5 from Arnd Bergmann ---
Created attachment 40596
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40596&action=edit
test case with correct whitespace
I thought I had tried it with the source pasted from the bug last time, but
t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061
--- Comment #29 from Jakub Jelinek ---
(In reply to Maxim Ostapenko from comment #28)
> > In short, the easiest fix is just to disable the initialization order
> > checking altogether for LTO (by forcing dynamically_initialized = 0 in LTO).
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78896
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79253
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79253
Bug ID: 79253
Summary: [7 Regression] ICE in tsubst_copy starting with
r243723
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79131
--- Comment #6 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #4)
> So, is this now fixed or is further work needed?
A further work is needed. There are a few different problems with the big
endian support. I'll submit more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79252
--- Comment #1 from Michael Meissner ---
Created attachment 40594
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40594&action=edit
Test case to show the various vec_inserts
Compile this code with -O2 -mcpu=power8, and look at the various
v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79251
Michael Meissner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79251
--- Comment #1 from Michael Meissner ---
Created attachment 40595
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40595&action=edit
File to show various vector inserts
Compile this file with -O2 -mcpu=power9 (or -O2 -mcpu=power8), and look
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79252
Bug ID: 79252
Summary: Improve code generation of vec_insert on PowerPC ISA
2.07 (i.e. power8)
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: enhanceme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79129
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78835
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79129
--- Comment #3 from Jakub Jelinek ---
Author: jakub
Date: Thu Jan 26 21:45:57 2017
New Revision: 244955
URL: https://gcc.gnu.org/viewcvs?rev=244955&root=gcc&view=rev
Log:
PR debug/79129
* dwarf2out.c (generate_skeleton_bottom_up)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78835
--- Comment #14 from Jakub Jelinek ---
Author: jakub
Date: Thu Jan 26 21:44:49 2017
New Revision: 244954
URL: https://gcc.gnu.org/viewcvs?rev=244954&root=gcc&view=rev
Log:
PR debug/78835
* dwarf2out.c (prune_unused_types): Mark a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79251
Michael Meissner changed:
What|Removed |Added
Priority|P3 |P5
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79251
Bug ID: 79251
Summary: PowerPC vec_insert generates store-hit-load if the
element number is variable
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: enh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78690
--- Comment #4 from Jakub Jelinek ---
Another testcase for this:
struct C;
template
struct A
{
struct C { static void bar (); };
};
template
struct B
{
using A::C;
void
foo () { C.bar (); }
};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79250
Bug ID: 79250
Summary: brig/brigfrontend/brig-to-generic.cc: two small
problems
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priorit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78703
--- Comment #9 from Martin Sebor ---
Author: msebor
Date: Thu Jan 26 21:14:18 2017
New Revision: 244953
URL: https://gcc.gnu.org/viewcvs?rev=244953&root=gcc&view=rev
Log:
PR middle-end/78703 -fprintf-return-value floating point handling incorrec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79131
--- Comment #5 from Dominik Vogt ---
The tests cases from the first message still fail using a cross compiler and
r244951.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79243
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79131
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79249
--- Comment #3 from Jonathan Wakely ---
Slightly further reduced:
template
auto attempt(FnT f)
{
return [f]()
{
try
{
f();
}
catch(...)
{
__builtin_puts("caught");
}
};
}
// More complex behavior doe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79249
--- Comment #2 from Jonathan Wakely ---
Reduced:
template
auto attempt(FnT f)
{
return [f]()
{
try
{
f();
}
catch(...)
{
__builtin_puts("caught");
}
};
}
// More complex behavior does not seem to mat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79249
Jonathan Wakely changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79249
Bug ID: 79249
Summary: Lambda call does not create exception handler.
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79244
--- Comment #6 from Jakub Jelinek ---
So here we have (ab) SSA_NAME as lhs and we try to replace it with non-(ab)
SSA_NAME, which isn't supported except for virtual operands.
So, one possibility I see is if lhs is (ab) and var is SSA_NAME that is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79165
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|dmalcolm at gcc d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67273
Nathan Sidwell changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79165
--- Comment #21 from David Malcolm ---
(In reply to David Malcolm from comment #19)
[...]
> In particular, repeated accesses to the same source line are more expensive
> that they could be: each time it tries to count forwards from the last
> lin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79165
--- Comment #20 from David Malcolm ---
Some other benchmarks spiked at same time (and recovered with the removal of
the bad linemap):
* "doduc" (from 3.5s up to to 4.s)
(with the bad linemap, get_next_line is 15% of the profile (in perf)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79244
--- Comment #5 from Jakub Jelinek ---
Slightly cleaned up testcase:
long buf[5];
int bar (void);
int
foo (int x)
{
int y = __builtin_setjmp (buf);
while (x != 3 && x && x && x != 2)
x = bar ();
return y;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79244
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79247
--- Comment #2 from Paul Romano ---
Thanks for clarifying!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68727
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79247
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79248
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79244
--- Comment #3 from David Binderman ---
Seems ok in revision 240685,so that gives a band of [240685, 241727)
for the bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70607
--- Comment #9 from Jonathan Wakely ---
Author: redi
Date: Thu Jan 26 19:40:02 2017
New Revision: 244951
URL: https://gcc.gnu.org/viewcvs?rev=244951&root=gcc&view=rev
Log:
PR libstdc++/70607 revert recent changes to
PR libstdc++/70607
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68727
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Thu Jan 26 19:39:40 2017
New Revision: 244949
URL: https://gcc.gnu.org/viewcvs?rev=244949&root=gcc&view=rev
Log:
PR c++/68727
* cp-tree.def (OFFSETOF_EXPR): Bump number of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79248
Bug ID: 79248
Summary: Typo in symtab.c:1032 "byt" instead of "but"
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: transl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65482
--- Comment #4 from Bill Schmidt ---
OK, that explains how we got here. At the moment, the usage of the flag only
matters to the test suite when running on older hardware. On P8, the test
suite uses -mpower8-vector rather than -mvsx -mno-allow-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79247
Bug ID: 79247
Summary: Race condition on OpenMP reduction variable
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79246
Bug ID: 79246
Summary: [C++17] with versioned namespace: FAIL:
27_io/manipulators/standard/wchar_t/2.cc (test for
excess errors)
Product: gcc
Version: 7.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79210
--- Comment #4 from David Malcolm ---
I'm not able to reproduce the assertion failure, with xgcc (GCC) 7.0.1 20170120
(experimental); on x86_64-pc-linux-gnu.
$ ./xgcc -B. -c /tmp/test.c -Wformat -Wformat-signedness
/tmp/test.c: In function ‘lpfc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79244
--- Comment #2 from David Binderman ---
Goes wrong in revision 241727, dated 20161101.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65482
--- Comment #3 from Michael Meissner ---
The -mallow-movmisalign option has always been a debug option. It was added in
the early power7 days. However, after benchmarking, we discovered that vectors
of 32-bit elements (i.e. vector int and vecto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79243
--- Comment #1 from Jonathan Wakely ---
Author: redi
Date: Thu Jan 26 18:32:55 2017
New Revision: 244945
URL: https://gcc.gnu.org/viewcvs?rev=244945&root=gcc&view=rev
Log:
Fix namespace versioning and remove __detail::__identity helpers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79244
Marek Polacek changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79245
--- Comment #1 from James Greenhalgh ---
Created attachment 40592
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40592&action=edit
Code generation for -Ofast -fomit-frame-pointer -mcpu=cortex-a72+crypto
-ftree-loop-distribute-patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79245
Bug ID: 79245
Summary: [7 Regression] Inefficient loop distribution to memcpy
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79244
Bug ID: 79244
Summary: ice in replace_uses_by, at tree-cfg.c:1866
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79239
--- Comment #8 from Richard Earnshaw ---
Patch posted here
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg02073.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79243
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79243
Bug ID: 79243
Summary: [7 Regression] Ambiguity with and
versioned namespaces
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Keywords: rejects-valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71374
--- Comment #5 from Vladimir Makarov ---
The problem is in that p88 does not conflict with a new reload pseudo created
to match p88 and the 3rd output (p91). They do not conflict as the reload
pseudo has the same value as p88.
So the solution i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79131
--- Comment #3 from Vladimir Makarov ---
Author: vmakarov
Date: Thu Jan 26 17:08:12 2017
New Revision: 244942
URL: https://gcc.gnu.org/viewcvs?rev=244942&root=gcc&view=rev
Log:
2017-01-26 Vladimir Makarov
PR target/79131
* lr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79176
--- Comment #7 from Jason Merrill ---
Author: jason
Date: Thu Jan 26 16:34:03 2017
New Revision: 244937
URL: https://gcc.gnu.org/viewcvs?rev=244937&root=gcc&view=rev
Log:
PR c++/79176 - lambda ICE with -flto -Os
* decl2.c (vague
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79176
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79240
--- Comment #6 from Dominik Vogt ---
(In reply to Jakub Jelinek from comment #5)
> Looking around, I see various spots that need cleanup:
> sizeof (HOST_WIDE_INT) * BITS_PER_UNIT should be IMHO HOST_BITS_PER_WIDE_INT
> 1ULL in unsigned HOST_WIDE_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76957
--- Comment #9 from amker at gcc dot gnu.org ---
(In reply to amker from comment #8)
> I will have a look. Thanks.
Tree dump is as below:
;; Function dsyr2k (dsyr2k, funcdef_no=0, decl_uid=4135, cgraph_uid=0,
symbol_order=3)
dsyr2k (long int N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79240
--- Comment #5 from Jakub Jelinek ---
Looking around, I see various spots that need cleanup:
sizeof (HOST_WIDE_INT) * BITS_PER_UNIT should be IMHO HOST_BITS_PER_WIDE_INT
1ULL in unsigned HOST_WIDE_INT contexts HOST_WIDE_INT_1U, 0ULL
HOST_WIDE_INT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79240
--- Comment #4 from Dominik Vogt ---
> So, either this is a bug in s390_extzv_shift_ok that is should use
> s390_contiguous_bitmask_p (contig, true, bitsize, &start, &end);
> instead of
> s390_contiguous_bitmask_nowrap_p (contig, bitsize, &star
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60833
--- Comment #2 from David Blaikie ---
ping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60815
--- Comment #3 from David Blaikie ---
ping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60246
--- Comment #1 from David Blaikie ---
ping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78265
--- Comment #3 from David Blaikie ---
ping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78322
--- Comment #3 from David Blaikie ---
ping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78321
--- Comment #1 from David Blaikie ---
ping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78320
--- Comment #1 from David Blaikie ---
ping
1 - 100 of 176 matches
Mail list logo
