[Bug c++/83473] pragma problems with raw string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83473 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-12-24 Version|5.4.0 |6.3.0 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- GCC 5 is no longer maintained.
[Bug c++/83484] constexpr not evaluated at compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83484
Jonathan Wakely changed:
What|Removed |Added
Keywords|link-failure|accepts-invalid
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-12-24
Ever confirmed|0 |1
--- Comment #4 from Jonathan Wakely ---
(In reply to Wilhelm M from comment #3)
> Here ist a simplified version of a MCVE:
>
> template
> struct X {
> static constexpr int x = 0;
> static constexpr int y = 1;
> };
>
> template<>
> constexpr int X<1>::x = 2; // should be ok, but gives duplicate
> initialization error
The compiler is correct.
> template<>
> constexpr int X<1>::y; // should be ill-formed (constexpr must be
> initialized), but gives undefined reference
How do you get an undefined reference if the previous definition gives an
error?
But I think you're right that it should be ill-formed, and that makes the
original testcase ill-formed. So the bug is "accepts-invalid" not
"link-failure".
[Bug libstdc++/83511] Missing default argument for basic_string_view::substr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83511 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2017-12-24 Ever confirmed|0 |1
[Bug c++/41874] Incorrect "dereferencing type-punned pointer will break strict-aliasing rules" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41874 --- Comment #14 from Jonathan Wakely --- (In reply to Aso Renji from comment #13) > Still have same problem in g++ 6.3.0. So, please reopen this bug. What do you mean by "same problem"? The original testcase does not produce a warning with GCC 6.3.0 If you get a warning for a different piece of code then please open a new bug, this one is fixed.
[Bug libstdc++/83450] FAIL: 21_strings/basic_string/pthread18185.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83450 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-12-24 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Control cannot reach the end of that function, but I assume pthread_exit isn't marked noreturn on HPUX.
[Bug middle-end/83557] missing last char in printf fmt string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83557
--- Comment #2 from m68k ---
Thanks for the feedback of this forgotten/unexpected behavior.
The funny part of this is, that the rules are not easy to adopt
see what printf("%c\r\n", 'A');
5.LC1:
6 0002 25630D0A .string "%c\r\n" <--printf("%c\r\n", 'A');
6 00
HERE \n is maintained, not taking into account puts behavior!!
\n is also maintained in some semantic wrong but syntax correct statement
see:
printf("\r\n"); with printf("\r\n", ' ');
3.LC0:
4 0D00 .string "\r" <---printf("\r\n");
5.LC1:
6 0002 0D0A00.string "\r\n"<---printf("\r\n", ' ');
and \n is also maintained when \n not at the end of a string
and see what printf("\n\r");
11.LC4:
12 000d 0A0D00.string "\n\r" <---printf("\n\r)");
[Bug middle-end/83557] missing last char in printf fmt string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83557
--- Comment #3 from m68k ---
Thanks for the feedback of this forgotten/unexpected behavior.
The funny part of this is, that the rules are not easy to adopt
see what printf("%c\r\n", 'A');
5 .LC1:
6 0002 25630D0A .string "%c\r\n" <--printf("%c\r\n", 'A');
6 00
HERE \n is maintained, not taking into account puts behavior!!
\n is also maintained in some semantic wrong but syntax correct statement
see and compare:
printf("\r\n"); with printf("\r\n", ' ');
3 .LC0:
4 0D00 .string "\r" <---printf("\r\n");
5 .LC1:
6 0002 0D0A00 .string "\r\n" <---printf("\r\n", ' ');
and \n is also maintained when \n not at the end of a string
see what printf("\n\r"); brings
11 .LC4:
12 000d 0A0D00 .string "\n\r" <---printf("\n\r)");
On 12/22/2017 04:57 PM, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83557
>
> Andrew Pinski changed:
>
> What|Removed |Added
>
> Status|UNCONFIRMED |RESOLVED
> Resolution|--- |INVALID
>
> --- Comment #1 from Andrew Pinski ---
> printf("\r\n");
>
> Gets converted into puts("\r"); as allowed by the C standard. The C standard
> says \n is a new line and puts will put a newline marker on the stdout.
>
> If you don't want this conversion use -fno-builtins, -fno-builtin-printf,
> -ffree-standing (I think that is the option name).
>
[Bug fortran/83540] [8 Regression] Invalid code with MATMUL, -fno-realloc-lhs -ffrontend-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83540 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #5 from Thomas Koenig --- (In reply to Harald Anlauf from comment #4) > (In reply to Dominique d'Humieres from comment #3) > > The code uses ALLOCATE without any realloc-lhs!-( > > The problem shows up for any use of MATMUL as argument > to a procedure, whether user-defined or intrinsic. > Maybe the problem is just related to the needed temporary. Correct, reallocation on assignment is used at the momemt for creating the temporaries if the bounds are unknown.
[Bug target/83008] [performance] Is it better to avoid extra instructions in data passing between loops?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83008 --- Comment #18 from sergey.shalnov at intel dot com --- Yes, I agree that vector_store stage has it’s own vectorization cost. And each vector_store has vector_construction stage. These stages are different in gcc slp (as you know). To better illustrate my point of view I would like to propose a patch. I didn’t submit the patch to community yet because I think it is better to discuss it before that. index 0ca42b4..72e3123 100644 --- a/gcc/tree-vect-slp.c +++ b/gcc/tree-vect-slp.c @@ -1825,7 +1825,7 @@ vect_analyze_slp_cost_1 (slp_instance instance, slp_tree node, record_stmt_cost (prologue_cost_vec, 1, vector_load, stmt_info, 0, vect_prologue); else if (dt == vect_external_def) - record_stmt_cost (prologue_cost_vec, 1, vec_construct, + record_stmt_cost (prologue_cost_vec, ncopies_for_cost, vec_construct, stmt_info, 0, vect_prologue); } }
[Bug libstdc++/68735] FAIL: libstdc++-prettyprinters/libfundts.cc print ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68735 --- Comment #3 from Jonathan Wakely --- Those Python exceptions come from GDB, but I'm not sure why.
[Bug c++/83533] error: no type named 'X' in 'using = ...'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83533 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.0 --- Comment #2 from Jonathan Wakely --- GCC 4.7.x has not been maintained or supported by the upstream GCC project for several years, and this is already fixed in GCC 4.8.0
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83538 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-12-24 Ever confirmed|0 |1
[Bug libstdc++/83450] FAIL: 21_strings/basic_string/pthread18185.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83450 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Sun Dec 24 09:17:38 2017 New Revision: 255992 URL: https://gcc.gnu.org/viewcvs?rev=255992&root=gcc&view=rev Log: PR libstdc++/83450 avoid -Wreturn-type warning in test PR libstdc++/83450 * testsuite/21_strings/basic_string/pthread18185.cc: Add return statement. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/21_strings/basic_string/pthread18185.cc
[Bug libstdc++/83450] FAIL: 21_strings/basic_string/pthread18185.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83450 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #3 from Jonathan Wakely --- Should be fixed now.
[Bug c++/41874] Incorrect "dereferencing type-punned pointer will break strict-aliasing rules" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41874 --- Comment #15 from Aso Renji --- (In reply to Jonathan Wakely from comment #14) > What do you mean by "same problem"? The original testcase does not produce a > warning with GCC 6.3.0 No, this warning still appear if (and only if) you use -O2 or -O3 optimization key (as it be in startpost with "g++ -O3 -Wstrict-aliasing test.cc -o /dev/null" line). If I don't use any optimization - yes, this warning don't appeared.
[Bug tree-optimization/83580] New: Wrong constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83580
Bug ID: 83580
Summary: Wrong constant folding
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ishiura-compiler at ml dot kwansei.ac.jp
Target Milestone: ---
GCC 8.0.0 for x86_64 miscompiles the following code.
% cat test.c
int a[2] = {0,1};
int x = 129;
int main (void)
{
volatile int v = 0;
int t = x;
for (int i = 0; i < (1+v+v+v+v+v+v+v+v+a[a[0]]); i++) {
t = a[(signed char)(130-x)];
}
if (t != 1) __builtin_abort();
return 0;
}
% gcc-8.0.0 test.c
% ./a.out
% gcc-8.0.0 test.c -O3
% ./a.out
zsh: abort (core dumped) ./a.out
% gcc-8.0.0 -v
Using built-in specs.
COLLECT_GCC=gcc-8.0.0
COLLECT_LTO_WRAPPER=/home/cappie/opt/gcc-8.0.0/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/home/cappie/opt/gcc-8.0.0 --disable-nls
--disable-multilib --program-suffix=-8.0.0 --enable-languages=c
Thread model: posix
gcc version 8.0.0 20171215 (experimental) (GCC)
[Bug rtl-optimization/83581] New: [8 Regression] ICE in expand_LOOP_VECTORIZED, at internal-fn.c:2397
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83581
Bug ID: 83581
Summary: [8 Regression] ICE in expand_LOOP_VECTORIZED, at
internal-fn.c:2397
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-8.0.0-alpha20171217 snapshot (r255766) ICEs when compiling the following
snippet w/ -O3 (-Ofast) -fno-tree-copy-prop -fno-tree-loop-im:
int ag, mv, v7;
int
nk (int g1)
{
int *yw = &g1;
while (ag < 1)
{
for (mv = 0; mv < 2; ++mv)
{
*yw += !!g1 + 1;
yw = &v7;
}
++ag;
}
return *yw;
}
% gcc-8.0.0-alpha20171217 -O3 -fno-tree-copy-prop -fno-tree-loop-im -c
ybdz3a46.c
during RTL pass: expand
ybdz3a46.c: In function 'nk':
ybdz3a46.c:4:1: internal compiler error: in expand_LOOP_VECTORIZED, at
internal-fn.c:2397
nk (int g1)
^~
0x61d137 expand_LOOP_VECTORIZED
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/internal-fn.c:2397
0x95f0c7 expand_call_stmt
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/cfgexpand.c:2587
0x95f0c7 expand_gimple_stmt_1
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/cfgexpand.c:3613
0x95f0c7 expand_gimple_stmt
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/cfgexpand.c:3779
0x9604b2 expand_gimple_basic_block
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/cfgexpand.c:5797
0x964a86 execute
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/cfgexpand.c:6403
[Bug c++/41874] Incorrect "dereferencing type-punned pointer will break strict-aliasing rules" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41874 Jonathan Wakely changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #16 from Jonathan Wakely --- (In reply to Richard Biener from comment #12) > No, the warning is gone from all releases that are still maintained. Looks like this wasn't true.
[Bug fortran/83567] Parametrized derived types: Segmentation fault when assigning a function return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83567
Paul Thomas changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-12-24
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Paul Thomas ---
Confirmed. Many thanks for the report.
The tree dump of addw shows what the problem is:
addvv (struct Pdtvec & restrict a, struct Pdtvec & restrict b)
{
integer(kind=8) D.3776;
void * restrict D.3777;
struct Pdtvec c;
try
{
c.k = 3;
c.k = a->k;
c.foo.dim[0].lbound = 1;
c.foo.dim[0].ubound = (integer(kind=8)) a->k;
c.foo.dim[0].stride = 1;
c.foo.offset = -1;
D.3776 = (integer(kind=8)) a->k * 4;
D.3777 = (void * restrict) __builtin_malloc (MAX_EXPR <(unsigned long)
D.3776, 1>);
c.foo.data = D.3777;
c.foo.dtype = 265;
{
...snip...
}
return c;
}
finally
{
if ((integer(kind=4)[0:] * restrict) c.foo.data != 0B)
{
__builtin_free ((void *) c.foo.data);
}
c.foo.data = 0B;
}
}
c%foo is being initialized correctly but is being freed on exit from the
function.
I will post the fix as soon as the regression testing is complete.
Paul
[Bug fortran/83567] Parametrized derived types: Segmentation fault when assigning a function return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83567 --- Comment #2 from Paul Thomas --- Created attachment 42962 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42962&action=edit A partial fix for the PR The attached patch clears the ICE and yields the correct result. However, there is still a memory leak because the automatically allocated parameterized component 'foo' of 'w' is not freed before the call to addw. I'll complete the fix, as soon as my tree is cleared of the fix for another PR that I am working on. Cheers Paul
[Bug c++/83533] error: no type named 'X' in 'using = ...'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83533 --- Comment #3 from Rostislav Povelikin --- (In reply to Jonathan Wakely from comment #2) > GCC 4.7.x has not been maintained or supported by the upstream GCC project > for several years, and this is already fixed in GCC 4.8.0 Hi Jonathan, Could you explain the nature of such bug? How to name it correctly? The bug wasn't reproduced by myself on Fedora 23,24,25 with the same compiler version. Is it related to Debian? Thanks
[Bug fortran/83560] list-directed formatting of INTEGER is missing plus on output when output open with SIGN='PLUS'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83560 --- Comment #6 from urbanjost at comcast dot net --- Thanks! As always, I am astonished at what has been accomplished. Fortran's viability itself depends so much on the availability of an open compiler.
[Bug ipa/83582] New: GCC is unable to fold the code of identical lambda-expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83582 Bug ID: 83582 Summary: GCC is unable to fold the code of identical lambda-expressions Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Case 1: https://godbolt.org/g/JvmxJr Case 2: https://godbolt.org/g/FWo12z It seems that the compiler should be able to pick up lambda functions with the same implementation, at least in a given translation unit.
[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 James Clarke changed: What|Removed |Added Attachment #42961|0 |1 is obsolete|| --- Comment #13 from James Clarke --- Created attachment 42963 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42963&action=edit Higher bits of paradoxical subregs on ia64 are undefined Thanks Jim, that makes sense. It seems to me that WORD_REGISTER_OPERATIONS should still be true on ia64 given the description in the documentation. This regression was introduced in r242326, which added the `&& !REG_P (SUBREG_REG (x))` to nonzero_bits1, thereby assuming that the high bits were defined, which is a target-specific assumption. The attached patch therefore encodes this assumption in whether WORD_REGISTER_OPERATIONS is positive or negative; I haven't modified any documentation as there's no point doing that if people disagree with this approach.
[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 --- Comment #14 from Segher Boessenkool --- (In reply to Jim Wilson from comment #11) > This part > > >r358 is known to have the high half zero: > > 22: r358:DI=r357:SI#0^r341:SI#0 > > is wrong. The upper bits of both registers are unknown bits, and xor of > unknown bits does not return zero. Yup, I don't know what I was thinking. > I think the problem is in nonzero_bits1 in rtlanal.c, in the SUBREG case. > On ia64, we have WORD_REGISTER_OPERATIONS true, and load_extend_op of SImode > is ZERO_EXTEND, so the code decides that the upper bits must be zero. But > LOAD_EXTEND_OP only applies to memory operations, and we do not have a > subreg of memory here, we have a subreg of a register. Right, that should be changed, that makes no sense at all. Will that fix the problem here? > When we have a > subreg of a reg, on itanium, the upper bits are unknown. So the > optimization performed here is wrong. Though one could perhaps argue that > the ia64 port is using WORD_REGISTER_OPERATIONS wrong I suppose. WORD_REGISTER_OPERATIONS isn't well-defined. """ @defmac WORD_REGISTER_OPERATIONS Define this macro to 1 if operations between registers with integral mode smaller than a word are always performed on the entire register. Most RISC machines have this property and most CISC machines do not. """ What operations? For some operations it can never be true (rotates, shifts, all slightly more complex operations). For machines that have explicit operations in more than one size it cannot be true, either. > I'm not sure what would happen if we removed that define. When I removed WORD_REGISTER_OPERATIONS from the rs6000 backend a few things regressed, but more things improved.
[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 --- Comment #15 from Eric Botcazou --- > Thanks Jim, that makes sense. It seems to me that WORD_REGISTER_OPERATIONS > should still be true on ia64 given the description in the documentation. I disagree, WORD_REGISTER_OPERATIONS means that the (general) registers are always modified as a whole by arithmetic operations. If that isn't the case, then the macro should not be defined (e.g Aarch64 doesn't define it although ARM does). > This regression was introduced in r242326, which added the `&& !REG_P > (SUBREG_REG (x))` to nonzero_bits1, thereby assuming that the high bits were > defined, which is a target-specific assumption. No, see above, WORD_REGISTER_OPERATIONS means that the bits are defined.
[Bug c++/83583] New: ICE in synthesize_implicit_template_parm, at cp/parser.c:38794
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83583
Bug ID: 83583
Summary: ICE in synthesize_implicit_template_parm, at
cp/parser.c:38794
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wouter at voti dot nl
Target Milestone: ---
The compiler ICE's on this construct. There are some simular bug reports which
might be the same problem or a related one, but they report a different
parser.c line.
using arm-eabi-gcc (GCC) 7.2.0 -fconcepts
code:
template< typename T >
concept bool has_main = requires {
{ T::main() } -> void;
};
template< typename T >
concept bool is_duration_with_polling = requires (
has_main m
){
{ template callback< m >::init() } -> void
};
[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 --- Comment #16 from Jim Wilson --- That referred patch was written by Eric Botcazou for PR59461 which is for SPARC, which operates same as Itanium, the upper 32-bits of a 32-bit value in a 64-bit reg are undefined. So it does not appear to be correct for SPARC either. Hence it appears that we need the same change for SPARC, and that breaks the fix for PR59461. I think we need to revisit that. If you have a paradoxical subreg of a reg, then it is only OK to use LOAD_EXTEND_OP if you know the value in the reg came from a memory location. This check is missing. If we are going to change the meaning of WORD_REGISTER_OPERATIONS, then we need a change to the docs also. But I'm not convinced that this needs to change.
[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 --- Comment #17 from James Clarke --- (In reply to Eric Botcazou from comment #15) > > Thanks Jim, that makes sense. It seems to me that WORD_REGISTER_OPERATIONS > > should still be true on ia64 given the description in the documentation. > > I disagree, WORD_REGISTER_OPERATIONS means that the (general) registers are > always modified as a whole by arithmetic operations. If that isn't the > case, then the macro should not be defined (e.g Aarch64 doesn't define it > although ARM does). Ok, fair enough, the docs are all I have to go on, as opposed to your existing knowledge of the codebase. > > This regression was introduced in r242326, which added the `&& !REG_P > > (SUBREG_REG (x))` to nonzero_bits1, thereby assuming that the high bits were > > defined, which is a target-specific assumption. > > No, see above, WORD_REGISTER_OPERATIONS means that the bits are defined. Well, yes and no, then. The regression on ia64 *was* introduced then, but only because of what you believe to be the existing incorrect use of WORD_REGISTER_OPERATIONS. I doubt there's much more I can contribute to this bug myself as I lack the knowledge of what is meant to happen deep inside GCC, but certainly I can confirm that the issue is with nonzero_bits returning only the lower 32 bits due to that if condition.
[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 --- Comment #18 from Jim Wilson --- SPARC defines WORD_REGISTER_OPERATIONS, and works the same as ia64. The upper bits of a 64-bit register after a 32-bit operation are don't care bits.
[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 --- Comment #19 from James Clarke --- (In reply to Jim Wilson from comment #16) > That referred patch was written by Eric Botcazou for PR59461 which is for > SPARC, which operates same as Itanium, the upper 32-bits of a 32-bit value > in a 64-bit reg are undefined. So it does not appear to be correct for > SPARC either. Hence it appears that we need the same change for SPARC, and > that breaks the fix for PR59461. I think we need to revisit that. If you > have a paradoxical subreg of a reg, then it is only OK to use LOAD_EXTEND_OP > if you know the value in the reg came from a memory location. This check is > missing. > > If we are going to change the meaning of WORD_REGISTER_OPERATIONS, then we > need a change to the docs also. But I'm not convinced that this needs to > change. The difference is that SPARC has instructions to operate on 32-bit values in the 64-bit registers, like many other RISC architectures, including for things like shifts.
[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
--- Comment #20 from Jim Wilson ---
I don't see the distinction here. Ia64 has instructions that operate on 32-bit
values too, like cmp4.
On sparc, given this testcase
int
sub (int i, int j, int k)
{
return i + j + k;
}
the compiler generates
sub:
add %o0, %o1, %o0
add %o0, %o2, %o0
jmp %o7+8
sra%o0, 0, %o0
Note that the add instruction operates on the entire 64-bit register, and after
the first add, we no longer have a valid 32-bit value, because there might have
been an overflow. This is why we need the sra at the end to sign-extend the
return value, because we know that the upper 32-bits are don't care bits.
If you take a paradoxical subreg of a SImode reg after an add instruction, you
can't make any assumptions about the upper 32-bits of the value in the
register. Exactly the same as ia64.
I do see that the fact that sparc has 32-bit shift instructions defined means
the testcase that fails on ia64 will not fail on sparc. But if we rely on that
for the WORD_REGISTER_OPERATIONS definition, then it gets even messier than it
already is.
If nonzero_bits1 isn't changed, then we may need to remove the
WORD_REGISTER_OPERATIONS definition in the ia64 port. Unfortunately, I don't
have access to ia64 hardware, so I can't easily check to see what will happen
if this is done.
[Bug ipa/83582] GCC is unable to fold the code of identical lambda-expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83582
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #1 from Andrew Pinski ---
Case 1:
#include
int main()
{
int arr[8];
auto sort = [] (auto x, auto y) { return false; };
std::sort(arr, arr + 8, sort);
std::sort(arr, arr + 8, sort);
std::sort(arr, arr + 8, sort);
std::sort(arr, arr + 8, sort);
std::sort(arr, arr + 8, sort);
std::sort(arr, arr + 8, sort);
std::sort(arr, arr + 8, sort);
std::sort(arr, arr + 8, sort);
std::sort(arr, arr + 8, sort);
}
Case 2:
#include
int main()
{
int arr[8];
std::sort(arr, arr + 8, [] (auto x, auto y) { return false; });
std::sort(arr, arr + 8, [] (auto x, auto y) { return false; });
std::sort(arr, arr + 8, [] (auto x, auto y) { return false; });
std::sort(arr, arr + 8, [] (auto x, auto y) { return false; });
std::sort(arr, arr + 8, [] (auto x, auto y) { return false; });
std::sort(arr, arr + 8, [] (auto x, auto y) { return false; });
std::sort(arr, arr + 8, [] (auto x, auto y) { return false; });
std::sort(arr, arr + 8, [] (auto x, auto y) { return false; });
std::sort(arr, arr + 8, [] (auto x, auto y) { return false; });
}
[Bug ipa/83582] GCC is unable to fold the code of identical lambda-expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83582 --- Comment #2 from Andrew Pinski --- Most likely because the requirement that two different lambdas need not to compare equal.
[Bug tree-optimization/83581] [8 Regression] ICE in expand_LOOP_VECTORIZED, at internal-fn.c:2397
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83581 Andrew Pinski changed: What|Removed |Added Target||x86_64-linux-gnu Component|rtl-optimization|tree-optimization Target Milestone|--- |8.0
[Bug libstdc++/83237] Values returned by std::poisson_distribution are not distributed correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83237 --- Comment #5 from paolo at gcc dot gnu.org --- Author: paolo Date: Sun Dec 24 22:08:52 2017 New Revision: 255993 URL: https://gcc.gnu.org/viewcvs?rev=255993&root=gcc&view=rev Log: 2017-12-24 Michele Pezzutti PR libstdc++/83237 * include/bits/random.tcc (poisson_distribution<>::operator()): Fix __x = 1 case - see updated Errata of Devroye's treatise. * testsuite/26_numerics/random/poisson_distribution/operators/ values.cc: Add test. * testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error line number. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/random.tcc trunk/libstdc++-v3/testsuite/26_numerics/random/poisson_distribution/operators/values.cc trunk/libstdc++-v3/testsuite/26_numerics/random/pr60037-neg.cc
[Bug c++/83533] error: no type named 'X' in 'using = ...'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83533 --- Comment #4 from Jonathan Wakely --- This was a bug in GCC 4.7.x which is fixed in GCC 4.8.0 We already fixed it, and do not support GCC 4.7 (or anything older than GCC 6), so there's nothing more we can do. Either use the workaround or use a newer version of GCC.
[Bug c/83584] New: "ISO C forbids conversion of object pointer to function pointer type" -- no, not really
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584
Bug ID: 83584
Summary: "ISO C forbids conversion of object pointer to
function pointer type" -- no, not really
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Keith.S.Thompson at gmail dot com
Target Milestone: ---
$ gcc --version
gcc (GCC) 7.1.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ cat c.c
int main(void) {
typedef void (func)(void);
void *ptr = 0;
func *fptr = (func*)ptr;
}
$ gcc -std=c11 -pedantic-errors -c c.c
c.c: In function ‘main’:
c.c:4:18: error: ISO C forbids conversion of object pointer to function pointer
type [-Wpedantic]
func *fptr = (func*)ptr;
^
$
In fact the conversion does not violate any syntax rule or constraint,
though its behavior is undefined.
N1570 6.5.4 p2-4 specifies the constraints on the cast operator. It
permits conversions between scalar types (which include pointer types). p4
specifically forbids conversions between pointer types and floating-point
types. There's nothing about pointer-to-function types.
6.3.2.3 defines the semantics of pointer conversions. It says nothing
about conversions between void* and pointer-to-function types -- which
means the behavior is undefined by omission.
The diagnostic should be a non-fatal warning when "-pedantic-errors"
is used, and it should be rephrased.
[Bug c/83584] "ISO C forbids conversion of object pointer to function pointer type" -- no, not really
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584 --- Comment #1 from Keith Thompson --- Tested on x86_64 Ubuntu 17.04, gcc 7.1.0 built from source
[Bug c/83584] "ISO C forbids conversion of object pointer to function pointer type" -- no, not really
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584 --- Comment #2 from Andrew Pinski --- Your reading of the spec is different than the GCC folks read it. See PR 11234 which requested the error in the first place. Note C11 and C89/C90 has not changed in this area as far as I can tell.
[Bug c/83584] "ISO C forbids conversion of object pointer to function pointer type" -- no, not really
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski --- Actually there is a common extension mentioned in N1570 about this case. J.5.7 [Function pointer casts] 1 A pointer to an object or to void may be cast to a pointer to a function, allowing data to be invoked as a function (6.5.4). 2 A pointer to a function may be cast to a pointer to an object or to void, allowing a function to be inspected or modified (for example, by a debugger) (6.5.4). - CUT This is not about undefined behavior being commonly defined either.
[Bug c/83584] "ISO C forbids conversion of object pointer to function pointer type" -- no, not really
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584 --- Comment #4 from Keith Thompson --- I'm aware that the standard has not changed in this area from C90 to C99 to C11. The conversion is undefined behavior, not a constraint violation, in all three editions. If the conversion is forbidden, what syntax rule or constraint does it violate?
[Bug other/83520] format string bug in libvtv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83520 --- Comment #3 from Touma Hatano --- Sorry for misleading. My point was that if we can replace snprintf (program_name, sizeof (program_name), program_invocation_name); with snprintf (program_name, sizeof (program_name), "%s", program_invocation_name); , the program won't crash when program_invocation_name contains format specifiers. How do you think?
[Bug rtl-optimization/83480] [8 Regression] ICE in create_block_for_bookkeeping, at sel-sched.c:4557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83480 --- Comment #3 from Arseny Solokha --- Likely a duplicate of PR80463.
[Bug target/83585] New: [8 Regression] Assembler messages: Error: can't resolve `.text' {.text section} - `.LCOLDB0' {.text.unlikely section}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83585
Bug ID: 83585
Summary: [8 Regression] Assembler messages: Error: can't
resolve `.text' {.text section} - `.LCOLDB0'
{.text.unlikely section}
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: assemble-failure
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gas 2.29.1 rejects the code generated by gcc-8.0.0-alpha20171217 snapshot
(r255766) w/ -O2 (-O3, -Ofast) -g -fno-tree-dce -fno-guess-branch-probability
for the following snippet:
int
j3 (int tz)
{
int wy;
for (wy = 0; wy < 2; ++wy)
if (tz != 0)
{
int yd;
for (yd = 0; yd < 2; ++yd)
{
}
return 0;
}
return;
}
% x86_64-pc-linux-gnu-gcc-8.0.0-alpha20171224 -O2 -g -fno-tree-dce
-fno-guess-branch-probability -w -c ixdsdxfe.c
/tmp/ccWUPZAP.s: Assembler messages:
/tmp/ccWUPZAP.s:215: Error: can't resolve `.text' {.text section} - `.LCOLDB0'
{.text.unlikely section}
/tmp/ccWUPZAP.s:216: Error: can't resolve `.text' {.text section} - `.LCOLDB0'
{.text.unlikely section}
/tmp/ccWUPZAP.s:220: Error: can't resolve `.text' {.text section} - `.LCOLDB0'
{.text.unlikely section}
/tmp/ccWUPZAP.s:221: Error: can't resolve `.text' {.text section} - `.LCOLDB0'
{.text.unlikely section}
/tmp/ccWUPZAP.s:228: Error: can't resolve `.text' {.text section} - `.LCOLDB0'
{.text.unlikely section}
/tmp/ccWUPZAP.s:229: Error: can't resolve `.text' {.text section} - `.LCOLDB0'
{.text.unlikely section}
[Bug fortran/83560] list-directed formatting of INTEGER is missing plus on output when output open with SIGN='PLUS'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83560 --- Comment #7 from Jerry DeLisle --- Patch posted here: https://gcc.gnu.org/ml/fortran/2017-12/msg00089.html
