Important m$6h?3p
This is a multi-part message in MIME format. Norman Virus Control a supprimé le message original qui contenait le virus [EMAIL PROTECTED]
Size of C/C++ data type from GNU GCC/g++ compiled ELF 64-bit LSB executable, AMD x86-64 vs. ELF 32-bit LSB executable, Intel 80386
Hi, I need experts to shed light on C/C++ data type size inconsistencies when running 64-bit and 32-bit ELF executables compiled by GNU/GCC g++/gcc Following are results of C/C++ data type size from code " cout << "data type" << sizeof(data type) << endl " : | 32-bit | 64-bit --- int |4 |4 --- long int |4 |8 --- signed long int |4 |4 --- ulong |4 |8 (sys/types.h) --- long double | 12 |16 Thank in advance, Tom -- View this message in context: http://www.nabble.com/Size-of-C-C%2B%2B-data-type-from-GNU-GCC-g%2B%2B-compiled-ELF-64-bit-LSB-executable%2C-AMD-x86-64-vs.-ELF-32-bit-LSB-executable%2C-Intel-80386-tf3942710.html#a11183699 Sent from the gcc - bugs mailing list archive at Nabble.com.
Re: GCJ built multithreaded program keeps creating zombies
>>>>> "Wolfgang" == Wolfgang Bangerth <[EMAIL PROTECTED]> writes: [ Wolfgang, I didn't meant to cut off the CCs in my earlier reply. Here it is again, with CCs preserved. ] Wolfgang> OK, I see, you set a mutex on exit of the new thread, and in Wolfgang> join() you just wait to get it. Is this right? Close. In Thread.join we wait on a condition variable. When a thread dies it signals this variable and all listeners wake up. Wolfgang> Then on Linux you will create a zombie for every thread you Wolfgang> create. But empirically this doesn't happen, because we create non-joinable threads. In fact if we tried to join them, pthread_join would just return an error (unless Linux egregiously violates POSIX or X/OPEN here). Wolfgang> Unfortunately, I can't find the place where you actually Wolfgang> create a new thread right away... _Jv_ThreadStart in libjava/posix-threads.cc. Tom
[Bug c/25384] New: gcc 4.0.2 compile fails on AIX 5.2: target bigtoc not found
Hello,
How can I modify my system to get gcc-4 compiled on AIX 5.2 ?
I always get the error "ld: target bigtoc not found".
Snippet of log below.
My System:
core file size(blocks, -c) 1048575
data seg size (kbytes, -d) 131072
file size (blocks, -f) 1048575
max memory size (kbytes, -m) 32768
open files(-n) 2000
pipe size (512 bytes, -p) 64
stack size(kbytes, -s) 32768
cpu time (seconds, -t) unlimited
max user processes(-u) 262144
virtual memory(kbytes, -v) unlimited
IBM F80, PowerPC_RS64-III, AIX 5.2.0.75, 500MHz CPU, 6 CPU
Thanks for your help in advance.
Thomas Baumann
/openpkg/bin/make --no-print-directory CC=" stage1/xgcc -Bstage1/
-B/openpkg/powerpc-ibm-aix5.2.0.0/bin/" CC_FOR_BUILD=" stage1/xgcc -Bstage1/
-B/openpkg/powerpc-ibm-aix5.2.0.0/bin/" \
STAGE_PREFIX=stage1/ \
ADAFLAGS="" CFLAGS="-pipe -O2 -fomit-frame-pointer"
LDFLAGS="-Wl,-bbigtoc" WARN_CFLAGS="\$(GCC_WARN_CFLAGS)" STRICT_WARN="-
pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition "
libdir=/openpkg/lib LANGUAGES="c gcov gcov-dump c++" MAKEINFO=
"/openpkg/RPM/TMP/gcc-4.0.2/missing makeinfo --split-size=500"
MAKEINFOFLAGS="--no-split" MAKEOVERRIDES= OUTPUT_OPTION="-o \$@" \
CFLAGS="-pipe -O2 -fomit-frame-pointer" WERROR=""
stage1/xgcc -Bstage1/ -B/openpkg/powerpc-ibm-aix5.2.0.0/bin/ -c -pipe -O2
-fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-Wno-variadic-macros -Wold-style-definition -DHAVE_CONFIG_H -
DGENERATOR_FILE -I. -Ibuild -I/openpkg/RPM/TMP/gcc-4.0.2/obj/../gcc
-I/openpkg/RPM/TMP/gcc-4.0.2/obj/../gcc/build -I/openpkg/RPM/TMP
/gcc-4.0.2/obj/../gcc/../include
-I/openpkg/RPM/TMP/gcc-4.0.2/obj/../gcc/../libcpp/include -o
build/genmodes.o /openpkg/RPM/TMP/gcc-4.0.2/obj/../gcc/genmodes.c
stage1/xgcc -Bstage1/ -B/openpkg/powerpc-ibm-aix5.2.0.0/bin/ -c -pipe -O2
-fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-Wno-variadic-macros -Wold-style-definition -DHAVE_CONFIG_H -
DGENERATOR_FILE -I. -Ibuild -I/openpkg/RPM/TMP/gcc-4.0.2/obj/../gcc
-I/openpkg/RPM/TMP/gcc-4.0.2/obj/../gcc/build -I/openpkg/RPM/TMP
/gcc-4.0.2/obj/../gcc/../include
-I/openpkg/RPM/TMP/gcc-4.0.2/obj/../gcc/../libcpp/include -o build/errors.o
/openpkg/RPM/TMP/gcc-4.0.2/obj/../gcc/errors.c
stage1/xgcc -Bstage1/ -B/openpkg/powerpc-ibm-aix5.2.0.0/bin/ -pipe -O2
-fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -W
strict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-Wno-variadic-macros -Wold-style-definition -DHAVE_CONFIG_H
-DGENERATOR_FILE -Wl,-bbigtoc -o build/genmodes \
build/genmodes.o build/errors.o
../build-powerpc-ibm-aix5.2.0.0/libiberty/libiberty.a
/openpkg/bin/ld: target bigtoc not found
collect2: ld returned 1 exit status
make[2]: *** [build/genmodes] Error 1
make[1]: *** [stage2_build] Error 2
make: *** [bootstrap-lean] Error 2
--
Summary: gcc 4.0.2 compile fails on AIX 5.2: target bigtoc not
found
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tom at tiri dot li
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25384
[Bug target/25384] gcc 4.0.2 compile fails on AIX 5.2: target bigtoc not found
--- Comment #2 from tom at tiri dot li 2005-12-16 15:54 --- Yes, without binutils it is working. I set following ulimits to make it compile: ulimit -c unlimited ulimit -d unlimited ulimit -f unlimited ulimit -m unlimited ulimit -s 131072 But one open question: I CAN COMPILE binutils-2.16.1 successfully, but why can't I use them? What is if i need to compile apps, which need binutils ? Thanks for your reply in advance. Thomas. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25384
[Bug c++/39170] New: -Wconversion useless
I'm sure this has been reported. General narrowing of a value (i,e double to int) needs to be reported, but bit-fields narrowing should not be reported unless asked for. There is nothing in "C" or "C++" to cast a bit-field, which in theory, would remove the warning. This is a serious problem and it makes gcc 4.3 not usable! Test case: Compile "gcc" with -Wconversion. Bit-field warnings need to be disabled We need a 4.3.3 patch otherwise we punt on 4.3 release. -- Summary: -Wconversion useless Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tom at atoptech dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39170
[Bug c/39170] -Wconversion useless
--- Comment #2 from tom at atoptech dot com 2009-02-12 18:10 ---
Subject: Re: -Wconversion useless
You miss the point. The only way to assign a non-constant value to a bit
field outside of a struct is using an integral variable i.e.,
struct foo
{
int a : 2;
};
void assign( struct foo v, int x )
{
v.a = x;
}
This results automatically in a warning. How do code this assignment
type-safe? There is no (bit-field) cast operator in the C or C++.
Like the "gcc" code base, our code does a lot bit-field assignments. We
no get thousands of warning using -Wconversion, this behavior makes the
option useless.
Again, compile the "gcc" code-base with "-Wconversion" and then you will
understand the problem.
Expect for bit-fields which are problematic to do potential bit-loss
(you must use with caution), you want warnings for implicit narrowing if
values, e.g., (double -> int)
void foo( int x );
...
double n;
foo(n)
The old behavior was just fine!
I'm sure many people do not even realize they are NOT getting implicit
conversions warnings anymore because they are not caught by "-Wall"
anymore. We only discovered this be tracing a bug in our code! We then
turned on "-Wconversion" only to discover thousands of warnings with no
way practical way to fix them.
Regards,
Tom Geocaris
On Thu, 2009-02-12 at 17:39 +, pinskia at gcc dot gnu dot org wrote:
>
> --- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-12 17:39
> ---
> Really -Wconversion is correct to warn about bit-fields because the conversion
> will lose bits.
>
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39170
[Bug c/39170] cannot silence -Wconversion warnings for bit-fields
--- Comment #4 from tom at atoptech dot com 2009-03-10 17:40 --- Manuel, You miss understood what I meant by "old behavior was just fine". I was saying that the previous behavior of "gcc" worked fine and I was NOT referring specifically to the "-Wconversion" option. The previous version of "gcc" warned when implicit narrowing of doubles to integral values, such as double n = 0.05; int d = n; when using the "-Wall" option. The behavior of "gcc" has changed. Moving all the conversion warnings to fall under "-Wconversion" may make semantic sense, but it alters the behavior of "gcc". We can fault ourselves for missing this change in the documentation, but there a level of expectation that the fundamental behavior of the compiler is consistent from release-to-release. And when fundamental behavior of "gcc" changes, ample notice should be given. People need to change Makefiles, alter code (if possible), etc... With regard to "-Wtraditional-conversion", it does not work when compiling "C++" code. > Do you think this would be an acceptable solution? (I don't know if this works > now in GCC 4.4) Absolutely not. It's not a portable solution. There is nothing in the "C++" standard (that I'm aware of) that suggests that "anding" an integral value with a "constant" value results in a truncated integral value. It's a bad hack. As you say, its is unfortunate that "C" and "C++" do not have a bit-field "cast-operators". But that is the reality. There is a lot of code written using "bit-fields". Look at "gcc" itself. Until the "C" or "C++" language contains a "type-safe" construct, such as a cast-operator, "gcc" should not issue a warning by default. If you have ideas on how to solve this, please submit them to the "C" or "C++" standards group. The "gcc" 4.3 stream is not safe (for us) to use as is. We need the compiler to issue warnings when implicit narrowing occurs (expect in the case of a bit-field). As is, we get thousands of warnings from our code when using "-Wconversion". Consequently, we are forced disable "-Wconversion" to suppress the bit-field warnings at the risk of missing other narrowing warnings. And this is not acceptable to us. We've already moved back to the 4.2 "gcc". Best Regards, Tom Geocaris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39170
[Bug c/39170] cannot silence -Wconversion warnings for bit-fields
--- Comment #6 from tom at atoptech dot com 2009-03-10 20:34 ---
Subject: Re: cannot silence -Wconversion warnings for
bit-fields
> AFAIK, that is not true. I just tried your very example with gcc 4.2.4 and it
> doesn't warn with -Wall -Wextra -Wconversion. g++ did warn but not with -Wall,
> you still needed to specify -Wconversion, and it did not warn in many cases.
> So
> please, check your facts.
You are correct in 4.2 you still need the -Wconversion option. We
upgraded from 3.4.6 to 4.2/4.3. In 3.4.6, gcc warned of this error
without any additional options.
> Fixing bugs alters behaviour. The change of behaviour was documented
> beyond what is normally expected.
You are splitting hairs. I don't see this change as a bug-fix. It's
along the lines to reinterpreting the "C" or "C++" language with regard
to bit-field assignments. The only way "C" or "C++" to assign a integral
variable a bit field is an assignment:
struct A
{
unsigned int v : 2;
}
void foo( A * a, int v ) { a->v = v; }
For which "gcc" now issues an warning for, always! And there is no
"language" defined way to eliminate this warning. Outside of writing
something ugly like:
struct A
{
union {
unsigned int v : 2;
unsigned int fill;
};
};
void foo( A * a, int v )
{
a->fill |= v & 0x3;
}
And if I have to write this, I might as well not use a bit-field!
Again, gcc 4.3.x now issues thousands of warnings (in our code) for
which we have NO reasonable and portable way to clean the code and NO
way to suppress the warning.
It makes the compiler (for us) not usable.
> Of course it doesn't. Have you understood what -Wtraditional-converion (and
> the
> old -Wconversion) actually warned for?
I don't care what "-Wconversion" previously did. We never used it, we
did not need to! In 3.4.6 the compiler issued the implicit conversion
warnings without additional options. In 4.2/4.3 you need -Wconversion to
get these warnings. In 4.2.4, "gcc" doesn't warn about bit-fields, but
in 4.3.x it does.
> Really? Then I have no ideas. In any case, someone else would need to
> take care of this because I do not have time. >
> http://gcc.gnu.org/faq.html#support
I don't understand why this change was made when "C" and the "C++"
language has no support for it...
Given this has not been been an issue with "C" for over 30 years, there
is probably a reason it is not in the language.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39170
[Bug c/94573] New: Optimizer produces suboptimal code related to -fstore-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94573
Bug ID: 94573
Summary: Optimizer produces suboptimal code related to
-fstore-merging
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at tom dot com
Target Milestone: ---
For the following code, we can known init the array C16DD is always
consecutive, so we can use the more bigger mode size.
test base on the x86-64 gcc 9.2 on https://gcc.godbolt.org/, now it is still
handled DWORD by DWORD, and we except optimize it with QWORD or more bigger
size.
extern signed int C16DD[43][12];
void C1F93(int index)
{
C16DD[index][0] = 0;
C16DD[index][1] = 0;
C16DD[index][2] = 0;
C16DD[index][3] = 0;
C16DD[index][4] = 0;
C16DD[index][5] = 0;
C16DD[index][6] = 0;
C16DD[index][7] = 0;
return;
}
= related assemble =
C1F93(int):
movsx rdi, edi
lea rax, [rdi+rdi*2]
sal rax, 4
mov DWORD PTR C16DD[rax], 0
mov DWORD PTR C16DD[rax+4], 0
mov DWORD PTR C16DD[rax+8], 0
mov DWORD PTR C16DD[rax+12], 0
mov DWORD PTR C16DD[rax+16], 0
mov DWORD PTR C16DD[rax+20], 0
mov DWORD PTR C16DD[rax+24], 0
mov DWORD PTR C16DD[rax+28], 0
ret
[Bug tree-optimization/95019] New: Optimizer produces suboptimal code related to -ftree-ivopts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95019
Bug ID: 95019
Summary: Optimizer produces suboptimal code related to
-ftree-ivopts
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at tom dot com
Target Milestone: ---
For the following code, we can known the variable C05A1 is only used for
the offset of array Dest and Src, and the unit size of the array is 8 bytes, so
an iv variable with step 8 will be good for targets, whose load/store insns
don't folded the lshift operand.
typedef unsigned long long UINT64;
void C0ADA(UINT64 len, long long *__restrict Src, long long *__restrict
Dest)
{
UINT64 C0ADD, index, C0068, offset, C0ADF;
UINT64 C05A1 = 0;
for (index = 0; index < len; index++) {
Dest[C05A1] = Src[C05A1] * Src[C05A1];
C05A1 += len - index;
}
}
test base on the MIPS64 gcc 5.4 on https://gcc.godbolt.org, as the MIPS64
target doesn't have load/store folded the lshift operand such as 'ldr x3,
[x1, x4, lsl 3]' in ARM64 targets , so use ivtmp with step 8 can eliminate the
dsll insn, which is in the kernel loop.
@@ -2,16 +2,17 @@ C0ADA(unsigned long long, long long*, long long*):
beq $4,$0,.L10 #, len,,
move$7,$0# C05A1,
+dsll$8,$4,3 # tmp, len << 3
+
.L4:
-dsll$2,$7,3 # D.2019, C05A1,
-daddu $3,$5,$2 # tmp204, Src, D.2019
+daddu $3,$5,$7 # tmp204, Src, D.2019
ld $3,0($3) # D.2021, *_10
-daddu $2,$6,$2 # tmp205, Dest, D.2019
+daddu $2,$6,$7 # tmp205, Dest, D.2019
dmult $3,$3 # D.2021, D.2021
daddu $7,$7,$4 # C05A1, C05A1, ivtmp.6
-daddiu $4,$4,-1 # ivtmp.6, ivtmp.6,
+daddiu $4,$4,-8 # ivtmp.6, ivtmp.6,
mflo$3 # D.2021
-bne $4,$0,.L4 #, ivtmp.6,,
+bne $8,$0,.L4 #, ivtmp.6,,
sd $3,0($2) # D.2021, *_8
.L10:
[Bug tree-optimization/95019] Optimizer produces suboptimal code related to -ftree-ivopts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95019
--- Comment #2 from zhongyunde at tom dot com ---
It is a generic issue for all targets, such as x86, it also don't enpand IVOPTs
as index is not used for DEST and Src directly. we may need expand IVOPTs, then
different targets can select different one according their Cost model.
Now, it seems ok for x86 as it have load/store insns folded the lshift operand,
so it doesn't need separate lshift operand in loop body .
== base on the ARM gcc 9.2.1 on https://gcc.godbolt.org, You'll get
separate lshift operand lsl in loop kernel, and ARM64 gcc 8.2 will use ldr
x3, [x1, x4, lsl 3] to avoid the separate lshift operand. so we can see all
target dont select an IV with Step 8.
C0ADA(unsigned long long, long long*, long long*):
push{r4, r5, r6, r7, lr}@
mov r4, r0@ len, tmp135
mov r5, r1@ len, tmp136
orrsr1, r4, r5 @ tmp137, len
beq .L1 @,
mov r1, #0@ C05A1,
.L3:
lsl r0, r1, #3@ _2, C05A1,
add ip, r2, r1, lsl #3@ tmp120, Src, C05A1,
ldr lr, [r2, r0] @ _4, *_3
ldr ip, [ip, #4] @ _4, *_3
umull r6, r7, lr, lr@ tmp125, _4, _4
mul ip, lr, ip@ tmp122, _4, tmp122
addsr1, r1, r4 @ C05A1, C05A1, len
subsr4, r4, #1 @ len, len,
sbc r5, r5, #0@ len, len,
add r0, r3, r0@ tmp121, Dest, _2
add r7, r7, ip, lsl #1@,, tmp122,
orrslr, r4, r5 @ tmp138, len
stm r0, {r6-r7} @ *_5, tmp125
bne .L3 @,
.L1:
pop {r4, r5, r6, r7, lr} @
bx lr @
Thanks for your notice.
[Bug c/95210] New: internal compiler error: in prepare_copy_insn, at gcse.c:1988
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95210
Bug ID: 95210
Summary: internal compiler error: in prepare_copy_insn, at
gcse.c:1988
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at tom dot com
Target Milestone: ---
rtx_insn *
prepare_copy_insn (rtx reg, rtx exp)
{
...
else
{
rtx_insn *insn = emit_insn (gen_rtx_SET (reg, exp));
if (insn_invalid_p (insn, false))
gcc_unreachable (); // here is the ICE ...
}
pat = get_insns ();
end_sequence ();
return pat;
}
As the function can_assign_to_reg_without_clobbers_p, we try to check an
temporary insn with regno 'FIRST_PSEUDO_REGISTER * 2'. So in some corner case,
such as a pattern with inout operand, the regno 'FIRST_PSEUDO_REGISTER * 2' is
just equal to the the regno in the REG_EQUAL （FIRST_PSEUDO_REGISTER = 117）,
then the temporary insn is valid, but it come fail when alloc another regno for
it, here is this issue.
(set (reg/v:V8HF16 236 )
(unspec: V8HF18 [ (reg: V8HF18 150)
(reg: V8HF18 236)] UNSPEC_MOVTVFM）)
(expr_list:REG_EQUAL (unspec: V8HF18 [ (reg: V8HF18 150)
(reg: V8HF18 234)] UNSPEC_MOVTVFM ))
bool
can_assign_to_reg_without_clobbers_p (rtx x, machine_mode mode)
{
/* Otherwise, check if we can make a valid insn from it. First initialize
our test insn if we haven't already. */
if (test_insn == 0)
{
test_insn
= make_insn_raw (gen_rtx_SET (gen_rtx_REG (word_mode,
FIRST_PSEUDO_REGISTER * 2),
const0_rtx));
SET_NEXT_INSN (test_insn) = SET_PREV_INSN (test_insn) = 0;
INSN_LOCATION (test_insn) = UNKNOWN_LOCATION;
}
/* Now make an insn like the one we would make when GCSE'ing and see if
valid. */
PUT_MODE (SET_DEST (PATTERN (test_insn)), mode);
SET_SRC (PATTERN (test_insn)) = x;
icode = recog (PATTERN (test_insn), test_insn, &num_clobbers);
[Bug c/95210] internal compiler error: in prepare_copy_insn, at gcse.c:1988
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95210
--- Comment #1 from zhongyunde at tom dot com ---
patch for this issue.
@ linux-9z2e in ~/software/gcc/gcc on git:master o [23:02:26]
$ git diff
diff --git a/gcc/gcse.c b/gcc/gcse.c
index 8b9518e..65982ec 100644
--- a/gcc/gcse.c
+++ b/gcc/gcse.c
@@ -853,7 +853,7 @@ can_assign_to_reg_without_clobbers_p (rtx x, machine_mode
mode)
{
test_insn
= make_insn_raw (gen_rtx_SET (gen_rtx_REG (word_mode,
- FIRST_PSEUDO_REGISTER * 2),
+ max_regno + 1),
const0_rtx));
[Bug rtl-optimization/95210] internal compiler error: in prepare_copy_insn, at gcse.c:1988
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95210 zhongyunde at tom dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from zhongyunde at tom dot com --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95267 *** This bug has been marked as a duplicate of bug 95267 ***
[Bug rtl-optimization/95267] [ICE][gcse]: in process_insert_insn at gcse.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95267 zhongyunde at tom dot com changed: What|Removed |Added CC||zhongyunde at tom dot com --- Comment #6 from zhongyunde at tom dot com --- *** Bug 95210 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/95696] New: regrename creates overlapping register allocations for vliw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95696
Bug ID: 95696
Summary: regrename creates overlapping register allocations for
vliw
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at tom dot com
Target Milestone: ---
In some target, it is limited to issue two insns with change the same
register.(The insn 73 start with insn:TI, so it will be issued together with
others insns until a new insn start with insn:TI, such as insn 71)
The regrename can known the mode V2VF in insn 73 need two successive registers,
i.e. v2 and v3, here is dump snippet before the regrename.
(insn:TI 73 76 71 4 (set (reg/v:V2VF 37 v2 [orig:180 _62 ] [180])
(unspec:V2VF [
(reg/v:VHF 43 v8 [orig:210 Dest_value ] [210])
(reg/v:VHF 43 v8 [orig:210 Dest_value ] [210])
] UNSPEC_HFSQMAG_32X32)) "../test_modify.c":57 710 {hfsqmag_v2vf}
(expr_list:REG_DEAD (reg/v:VHF 43 v8 [orig:210 Dest_value ] [210])
(expr_list:REG_UNUSED (reg:VHF 38 v3)
(expr_list:REG_STAGE (const_int 2 [0x2])
(expr_list:REG_CYCLE (const_int 2 [0x2])
(expr_list:REG_UNITS (const_int 256 [0x100])
(nil)))
(insn 71 73 243 4 (set (reg:VHF 43 v8 [orig:265 MEM[(const vfloat32x16
*)Src_base_134] ] [265])
(mem:VHF (reg/v/f:DI 13 a13 [orig:207 Src_base ] [207]) [1 MEM[(const
vfloat32x16 *)Src_base_134]+0 S64 A512])) "../test_modify.c":56 450
{movvhf_internal}
(expr_list:REG_STAGE (const_int 1 [0x1])
(expr_list:REG_CYCLE (const_int 2 [0x2])
(nil
Then, in the regrename, the insn 71 will be transformed into following code
with register v3, so there is an conflict between insn 73 and insn 71, as both
of them set the v3 register.
Register v2 (2): 73 [SVEC_REGS]
Register v8 (1): 71 [VEC_ALL_REGS]
(insn 71 73 243 4 (set (reg:VHF 38 v3 [orig:265 MEM[(const vfloat32x16
*)Src_base_134] ] [265])
(mem:VHF (reg/v/f:DI 13 a13 [orig:207 Src_base ] [207]) [1 MEM[(const
vfloat32x16 *)Src_base_134]+0 S64 A512])) "../test_modify.c":56 450
{movvhf_internal}
(expr_list:REG_STAGE (const_int 1 [0x1])
(expr_list:REG_CYCLE (const_int 2 [0x2])
[Bug rtl-optimization/95696] regrename creates overlapping register allocations for vliw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95696 zhongyunde at tom dot com changed: What|Removed |Added CC||zhongyunde at tom dot com --- Comment #1 from zhongyunde at tom dot com --- Created attachment 48739 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48739&action=edit Step 7: Close chains for registers that were never really used delayed at the end of vliw I make a patch, please help to review, tks.
[Bug rtl-optimization/96031] New: suboptimal codegen for store low 16-bits value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96031
Bug ID: 96031
Summary: suboptimal codegen for store low 16-bits value
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at tom dot com
Target Milestone: ---
For the following code, as instruction strh only store the low 16-bits value,
so the 'and w2, w2, 65535 ' is redundant.
test base on the ARM64 gcc 8.2 on https://gcc.godbolt.org/, so get complicated
assemble.
typedef unsigned int UINT32;
typedef unsigned short UINT16;
UINT16 array[12];
void foo (UINT32 len, UINT32 step)
{
UINT32 index = 1;
for (index = 1 ; index < len; index++ )
{
array[index] = index * step;
}
}
// the assemble of kernel loop body --
b .L4 //
.L6:
add x3, x3, 2 // ivtmp.6, ivtmp.6,
.L4:
strhw2, [x4, 2] // ivtmp.4, MEM[base: _2, offset: 2B]
add w2, w1, w2// tmp105, _12, ivtmp.4
and w2, w2, 65535 // ivtmp.4, tmp105
cmp x3, x0// ivtmp.6, _23
mov x4, x3// ivtmp.6, ivtmp.6
bne .L6 //,
[Bug rtl-optimization/96031] suboptimal codegen for store low 16-bits value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96031
--- Comment #1 from zhongyunde at tom dot com ---
this may can be enhance by ivopts.
If the case adjusted as following, then the 'and w2, w2, 65535 ' will
disappear.
typedef unsigned int UINT32;
typedef unsigned short UINT16;
UINT16 array[12];
void foo (UINT32 len, UINT32 step)
{
UINT32 index = 0;
UINT32 sum = 0;
for (index = 0; index < len; index++ )
{
array[index] = sum;
sum += step;
}
}
// the assemble of kernel loop body --
.L9:
add x2, x2, 2 // ivtmp.6, ivtmp.6,
.L3:
strhw3, [x4]// sum, MEM[base: _12, offset: 0B]
cmp x2, x0// ivtmp.6, _22
add w3, w3, w1// sum, sum, step
mov x4, x2// ivtmp.6, ivtmp.6
bne .L9 //,
[Bug rtl-optimization/95696] regrename creates overlapping register allocations for vliw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95696 --- Comment #3 from zhongyunde at tom dot com --- (In reply to Richard Biener from comment #2) > Please send patches to gcc-patc...@gcc.gnu.org I have send this patch by email according your suggestion, please give me some advice, thanks!
[Bug rtl-optimization/96031] suboptimal codegen for store low 16-bits value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96031
--- Comment #3 from zhongyunde at tom dot com ---
I find there is some different between the two cases during in ivopts.
For the 2nd case, a UINT32 type iv sum is choosed
[local count: 955630224]:
# sum_15 = PHI <0(5), sum_9(6)>
# ivtmp.10_17 = PHI
_2 = (short unsigned int) sum_15;
_1 = _2;
_11 = (void *) ivtmp.10_17;
MEM[base: _11, offset: 0B] = _1;
sum_9 = step_8(D) + sum_15;
ivtmp.10_4 = ivtmp.10_17 + 2;
if (ivtmp.10_4 != _22)
goto ; [89.00%]
For the 1st case, a 'short unsigned int type' ivtmp.8 is choosed as your dump
showed, and there is no UINT32 type candidate with Step step.
typedef unsigned int UINT32;
typedef unsigned short UINT16;
UINT16 array[12];
void foo (UINT32 len, UINT32 step)
{
UINT32 index = 0;
UINT32 sum = 0;
for (index = 0; index < len; index++ )
{
sum = index * step;
array[index] = sum;
}
}
I tried to add a UINT32 type temporary sum as above case （the 3rd case）, then
modify the gcc to add an UINT32 type candidate variable and adjust the cost to
choose the Candidate variable （do the similar things as the 2nd case in ivopt）,
then we can also optimize the 'and w2, w2, 65535' insn.
But above method is not conformed to the implementation method of ivopt, may be
we need extend an UINT32 candidate variable base 'on short unsigned int' IV
struct ?
= the change of gcc to add UINT32 type candidate variable
==
@@ -3389,7 +3389,7 @@ add_iv_candidate_for_bivs (struct ivopts_data *data)
EXECUTE_IF_SET_IN_BITMAP (data->relevant, 0, i, bi)
{
iv = ver_info (data, i)->iv;
- if (iv && iv->biv_p && !integer_zerop (iv->step))
+ if (iv && !integer_zerop (iv->step))
add_iv_candidate_for_biv (data, iv);
}
}
[Bug c/96427] New: Missing align attribute for anchor section from local variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96427
Bug ID: 96427
Summary: Missing align attribute for anchor section from local
variables
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at tom dot com
Target Milestone: ---
For the following code, we can known the local array a_1 is aligned 64 bytes,
but now gcc only aligned to default 32 bytes for related anchor data.
== test case
int bar (long long v);
int foo (int i)
{
long long v;
int a_1[131] __attribute__((aligned(64))) = {38580, 691093, 378582, 691095,
938904, 251417, 38906, 251419, 2938908, 251421, 938910, 4863, 92352, 104865,
792354, 4867, 2792356,251429, 938918,251431, 938920,251433, 938922, 104875,
22792364, 104877, 2792366, 104879, 2792368, 104881, 6180210,8492723,
6180212,8492725,
6180214,8492727,33656,346169,33658,346171,33660,346173,33662,8492735,
6180224,8492737, 6180226,8492739,
6180228,346181,33670,346183,33672,346185,33674,7906507, 593996,7906509,
593998,7906511, 594000,7906513,447442,7759955,447444,7759957,447446,7759959,
594008,7906521, 594010,7906523, 594012,7906525,
594014,7759967,447456,7759969,447458,7759971,447460,8492773, 6180262,8492775,
6180264,8492777, 6180266,346219,33708,346221,33710,346223,33712,346225,
6180274,8492787, 6180276,8492789,
6180278,8492791,33720,346233,33722,346235,33724,346237,33726,7906559,
594048,7906561, 594050,7906563,
594052,7760005,447494,7760007,447496,7760009,447498,7906571, 594060,7906573,
594062,7906575, 94064, 7906577, 447506, 760019, 447508, 760021, 447510};
const long long * ptr = (const long long *)a_1;
v = ptr[0];
return bar (v);
}
= test base on the X86 gcc 9.3 on https://gcc.godbolt.org =
.text
.Ltext0:
.section .rodata
.align 32 # here, use the default alignment 32 byte of section .rodata
.LC0:
.long 38580
.long 691093
.long 378582
...
foo(int):
mov rdi, QWORD PTR .LC0[rip]
jmp bar(long long)
[Bug rtl-optimization/95696] regrename creates overlapping register allocations for vliw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95696 --- Comment #6 from zhongyunde at tom dot com --- Thanks for you notes and I thinks this issue can be closed now. It doesn't need to handle of non-SMS cases as they'll reschedule in general, which is good for performance under my test.
[Bug c/96427] Missing align attribute for anchor section from local variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96427 --- Comment #2 from zhongyunde at tom dot com --- should the data alignment honor the user specified ? Now, it seems compiler _do_ align the initializer according align load. so even if the local array doesn't specify the __attribute__((aligned(64))), it still align to 64 bytes.
[Bug tree-optimization/93102] [optimization] is it legal to avoid accessing const local array from stack ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93102
--- Comment #4 from zhongyunde at tom dot com ---
case from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96427 generates *.LC0,
but don't emit an aggregate copy a_1 = *.LC0, i.e. it is legal even for
non-const local array.
typedef int v4si __attribute__((vector_size(64)));
int bar (v4si v);
int foo (int i)
{
int a_1[131] = {38580, 691093, 378582, 691095, 938904, 251417, ... };
v4si * ptr = (v4si *)a_1;
v4si v = ptr[0];
return bar (v);
}
[Bug c/96586] New: suboptimal code generated for condition expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96586
Bug ID: 96586
Summary: suboptimal code generated for condition expression
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at tom dot com
Target Milestone: ---
For the following case, we can easy known the while loop will execute once, but
with newest gcc 10.2, it still generated suboptimal code with condition
expression.
void Proc_7 (int Int_Par_Ref);
void Proc_2 (int *Int_Par_Ref);
int main ()
{
int Int_1_Loc;
int Int_2_Loc;
int Int_3_Loc;
/* Initializations */
Int_1_Loc = 2;
Int_2_Loc = 3;
while (Int_1_Loc < Int_2_Loc)
{
Proc_7 (0);
Int_1_Loc += 1;
} /* while */
Int_1_Loc = 1;
Proc_2 (&Int_1_Loc);
return 0;
}
== the key assemble of the while loop ===
.L2:
.loc 1 18 7 view .LVU10
.loc 1 20 7 view .LVU11
.loc 1 20 14 is_stmt 0 view .LVU12
mov edi, 5
callProc_7(int)
.LVL1:
.loc 1 22 7 is_stmt 1 view .LVU13
.loc 1 22 17 is_stmt 0 view .LVU14
mov eax, DWORD PTR [rsp+12]
add eax, 1
mov DWORD PTR [rsp+12], eax
.loc 1 16 5 is_stmt 1 view .LVU15
.loc 1 16 22 view .LVU16
cmp eax, 2
jle .L2
[Bug c/96427] Missing align attribute for anchor section from local variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96427 --- Comment #6 from zhongyunde at tom dot com --- Created attachment 49087 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49087&action=edit adjust the alignment according the attibute If user don't specify the alignment, so we can do some optimization. otherwise, we can obey it firstly, similiar to the patch attached?
[Bug rtl-optimization/96031] suboptimal codegen for store low 16-bits value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96031 --- Comment #4 from zhongyunde at tom dot com --- > As for ivopt, I can see a minor improvement by replacing != exit condition > with <=, thus saving add 2 instruction computing _22, which happens to > "disable" the wrong PRE transformation. > I take a look at the function may_eliminate_iv, now iv_elimination_compare will only return EQ_EXPR or NE_EXPR, so do you mean to do some extend for this case? 5411 *bound = fold_convert (TREE_TYPE (cand->iv->base), 5412 aff_combination_to_tree (&bnd)); 5413 *comp = iv_elimination_compare (data, use); 5414
[Bug preprocessor/91412] Unexpectedly correct raw string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91412 Tom Honermann changed: What|Removed |Added CC||tom at honermann dot net --- Comment #1 from Tom Honermann --- My understanding is that the usual rationale for removal of trailing whitespace is to consider it part of a newline sequence; similar to considering as a single newline. Using that rationale, it seems appropriate that the spaces be retained as part of translation phase 2 reversion; just as it would presumably be desirable to preserve a sequence through such reversion.
[Bug c++/69089] C++11: alignas(0) causes an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69089 Tom de Geus changed: What|Removed |Added CC||tom at geus dot me --- Comment #7 from Tom de Geus --- Same problem here. It would be great if the patch could be integrated!
[Bug c++/40942] GCC accepts code that Comeau and MSVC deems invalid.
--- Comment #4 from tom at kera dot name 2009-08-25 14:48 --- (In reply to comment #2) > Why would this be ambiguous? A string literal has type "array of n const char" > (see 2.13.4/1), so it should go with the array constructor. Do you disagree? > > W. > Table 9 under 13.3.3/1 shows that array-to-pointer conversion is Exact Match. As is rvalue-to-lvalue conversion (though string literals are lvalues anyway :D). As is Identity, which is what applies here. There is no clear ranking between them, hence Comeau reporting ambiguity. Although I personally think Identity should overrule absolutely everything, it doesn't. So IMO GCC is buggy in this way. -- tom at kera dot name changed: What|Removed |Added CC| |tom at kera dot name http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40942
[Bug other/42081] New: big-endian arm MULTILIB_DEFAULTS hard-coded to little-endian
To whom it may concern:
In general, the logic of the gcc/config/arm/linux-elf.h file dictates that if
the target is big-endian arm, gcc will use big-endian defaults (like
-mbig_endian); otherwise, gcc will use little-endian defaults. However, there
is apparently one exception to this rule. MUTLILIB_DEFAULTS is hard-coded to
little-endian for both big-endian and little-endian arm:
#undef MULTILIB_DEFAULTS
#define MULTILIB_DEFAULTS \
{ "marm", "mlittle-endian", "mhard-float", "mno-thumb-interwork" }
To be to consistent with the rest of the header file, shouldn't this read:
#undef MULTILIB_DEFAULTS
#if TARGET_BIG_ENDIAN_DEFAULT
#define MULTILIB_DEFAULTS \
{ "marm", "mbig-endian", "mhard-float", "mno-thumb-interwork" }
#else
#define MULTILIB_DEFAULTS \
{ "marm", "mlittle-endian", "mhard-float", "mno-thumb-interwork" }
#endif
or better yet:
#undef MULTILIB_DEFAULTS
#define MULTILIB_DEFAULTS \
{ "marm", TARGET_ENDIAN_OPTION, "mhard-float", "mno-thumb-interwork" }
Otherwise, on a big-endian arm target in which multi-lib is enabled,
potentially some options would be set by default to big-endian, others to
little-endian, and the compiler would get confused. At least that's how it
appears to me.
If this is by design rather than a minor bug that fell through the cracks (I
know that arm is natively little-endian, and thus there may be a reason to
always default it to little-endian in certain cases) please disregard this
message and close this bug report. Thanks.
Regards,
Tom
--
Summary: big-endian arm MULTILIB_DEFAULTS hard-coded to little-
endian
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tom at giftssoft dot com
GCC target triplet: arm*b-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42081
[Bug middle-end/46935] We should recognize expanded switch statement and convert 2 way switch statements into shift & mask test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46935 Tom de Vries changed: What|Removed |Added CC||tom at codesourcery dot com --- Comment #5 from Tom de Vries 2011-01-14 13:17:09 UTC --- > I know Tom de Vries is working on this problem and has a prototype patch. > He'll be posting his work for 4.7. http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00959.html
[Bug tree-optimization/14799] [tree-ssa] convert a sequence of "if"s to a "switch" statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14799
Tom de Vries changed:
What|Removed |Added
CC||tom at codesourcery dot com
--- Comment #3 from Tom de Vries 2011-01-14
15:45:56 UTC ---
The example from the description field looks like this at tree level (optimized
dump with 4.5.1). It takes until late in the rtl untill the duplicate call
blocks are collapsed.
...
foo (int a)
{
:
if (a_1(D) == 30)
goto ;
else
goto ;
:
bar (); [tail call]
goto ;
:
if (a_1(D) == 31)
goto ;
else
goto ;
:
bar (); [tail call]
goto ;
:
if (a_1(D) == 53)
goto ;
else
goto ;
:
bar (); [tail call]
goto ;
:
if (a_1(D) == 23)
goto ;
else
goto ;
:
bar (); [tail call]
:
return;
}
...
If the duplicate blocks would have been collapsed, it would look like this:
...
foo (int a)
{
:
if (a_1(D) == 30)
goto ;
else
goto ;
:
if (a_1(D) == 31)
goto ;
else
goto ;
:
if (a_1(D) == 53)
goto ;
else
goto ;
:
if (a_1(D) == 23)
goto ;
else
goto ;
:
bar (); [tail call]
:
return;
}
...
for this representation, the patch from PR 46935 comment 5 should work.
[Bug middle-end/46935] We should recognize expanded switch statement and convert 2 way switch statements into shift & mask test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46935 --- Comment #6 from Tom de Vries 2011-01-14 15:48:03 UTC --- Related bug: PR 14799.
[Bug tree-optimization/50304] New: poor code for accessing certain element of arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50304
Bug #: 50304
Summary: poor code for accessing certain element of arrays
Classification: Unclassified
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: t...@deltasystem.hu
Array elements on known (hardcoded) positions are accessed by inefficient code.
The addresses are computed runtime, waisting both runtime and code size. For
example:
int a[4][4][16];
void foo( void )
{
int c;
c = a[2][3][4];
...
}
compiles this way in -O1, ARM Cortex M0:
0:4b02 ldrr3, [pc, #8]; (c )
2:22b4 movsr2, #180; 0xb4
4:0092 lslsr2, r2, #2
6:589a ldrr2, [r3, r2]
---
I tried to convert this operation to be precompiled by forming a constant
address.
int a[4][4][16];
int *const b=&a[2][3][4];
void foo( void )
{
int c;
c = *b;
...
}
However, it is ignored by gcc, and compiles this way in -O1:
0:4b03 ldrr3, [pc, #12]; (10 )
2:21b4 movsr1, #180; 0xb4
4:0089 lslsr1, r1, #2
6:185a addsr2, r3, r1
8:6812 ldrr2, [r2, #0]
The actual code can vary, depending on the situation. For example:
0:4b02 ldrr3, [pc, #8]; (c )
2:4a03 ldrr2, [pc, #12]; (10 )
4:589a ldrr2, [r3, r2]
or
0:4b02 ldrr3, [pc, #8]; (c )
2:4903 ldrr1, [pc, #12]; (10 )
4:185a addsr2, r3, r1a[0][0][0]=c;
6:6812 ldrr2, [r2, #0]
Sometimes (I don't know yet why and exactly when) it can be even much worse,
introducing bytewide accessing of e.g. an int32_t, dissassembling and
reassembling it. (It's definetely not an alignment problem.) This waists about
40 instructions for a read-modify-write access.
--
It should have look like this:
0:4b02 ldrr3, [pc, #8]; (c )
2:681b ldrr3, [r3, #0]
4:681a ldrr2, [r3, #0]
where the constant (at 0x0c) at the first row is a precalculated address.
--
With variable address, like this:
int a[4][4][16];
int *b=&a[2][3][4];
...
it work nicely. However, it is really not equivalent solution at flash based
processors.
[Bug target/50304] poor code for accessing certain element of arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50304 --- Comment #2 from Tamas Fenyvesi 2011-09-08 13:14:44 UTC --- Created attachment 25225 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25225 some testcases
[Bug target/50304] poor code for accessing certain element of arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50304 --- Comment #3 from Tamas Fenyvesi 2011-09-08 13:16:20 UTC --- Created attachment 25226 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25226 -O1..-O3 compiled objdumped result
[Bug target/50304] poor code for accessing certain element of arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50304 --- Comment #4 from Tamas Fenyvesi 2011-09-08 13:16:53 UTC --- Please find a sample code and its objdump-ed asm in the attachment. The command line is: arm-none-eabi-gcc -D__REDLIB__ -DDEBUG -D__USE_CMSIS -D__CODE_RED -I"../cmsis" -I"../config" -I"../driver" -O1 -g3 -Wall -c -fmessage-length=0 -fno-builtin -ffunction-sections -fdata-sections -mcpu=cortex-m0 -mthumb -MMD -MP -MF"src/bugreport.d" -MT"src/bugreport.d" -o"src/bugreport.o" "../src/bugreport.c" Some comments: -It is the same from -O1 up to -O3. The -O0 is worse. -Access of an int array differs somewhat but both have adding (or relative) operation. Access of a struct doesn't differ in anything whether or not uses a *const. -All (* const) should have been exist (rather than have been replaced by some adding of two (or more) other adders). It definetely costs more (in code area) to have some offset vector and adding code than to have a precomputed ofsetted address (even if the base address were stored elsewhere), not to mention the huge wasted runtime. There can appear several cascaded adding operations for computing a single address. The code is larger and much slower, plus it needs more register to allocate, which in turn also increase code size and required runtime. -Why does the compiler resolve the mode of computing the ofsetted address instead of simply materializing a *const if the user explicitly instructs it to hace a *const? The code can have any number of copies of *const address (as it can't change) if it were required for e.g. a pc-relative loading. There's simply no point in not direct materializing any *const. -Precompiling any known addesses and adding only the variables, on the other hand, is good practice (and not uncommon in other compilers than gcc), even without any *const. (E.g. for "a[1][2][var]" it should precompile "a[1][2]" and add only "var".)
[Bug libstdc++/52169] the ifstream readsome() method does not signal any bit on eof.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52169 Tomalak Geret'kal changed: What|Removed |Added CC| |tom at kera dot name --- Comment #1 from Tomalak Geret'kal 2012-02-08 10:39:54 UTC --- cplusplus.com is (a) not authoritative, (b) full of mistakes, and (c) otherwise just awful. Instead, we'll quote the standard(s): [C++11: 27.7.2.3]: streamsize readsome(char_type* s, streamsize n); 32/ Effects: Behaves as an unformatted input function (as described in 27.7.2.3, paragraph 1). After constructing a sentry object, if !good() calls setstate(failbit) which may throw an exception, and return. Otherwise extracts characters and stores them into successive locations of an array whose first element is designated by s. If rdbuf()->in_avail() == -1, calls setstate(eofbit) (which may throw ios_base::failure (27.5.5.4)), and extracts no characters; — If rdbuf()->in_avail() == 0, extracts no characters — If rdbuf()->in_avail() > 0, extracts min(rdbuf()->in_avail(),n)). 33/ Returns: The number of characters extracted. [C++03: 27.6.1.3]: streamsize readsome(char_type* s, streamsize n); 30/ Effects: Behaves as an unformatted input function (as described in 27.6.1.3, paragraph 1). After constructing a sentry object, if !good() calls setstate(failbit) which may throw an exception, and return. Otherwise extracts characters and stores them into successive locations of an array whose first element is designated by s. If rdbuf()->in_avail() == -1, calls setstate(eofbit) (which may throw ios_base::failure (27.4.4.3)), and extracts no characters; — If rdbuf()->in_avail() == 0, extracts no characters — If rdbuf()->in_avail() > 0, extracts min(rdbuf()->in_avail(),n)). 31/ Returns: The number of characters extracted.
[Bug libstdc++/52169] the ifstream readsome() method does not signal any bit on eof.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52169 --- Comment #2 from Tomalak Geret'kal 2012-02-08 10:45:17 UTC --- Are you sure it's not just that in_avail is 0? Why should it be -1 here? i.e. doesn't readsome become a noop when there's nothing to read?
[Bug libstdc++/52015] std::to_string does not work under MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52015 Tomalak Geret'kal changed: What|Removed |Added CC| |tom at kera dot name --- Comment #23 from Tomalak Geret'kal --- Nathan, read comment 15. :)
[Bug libstdc++/53984] iostream operation throwing exception when exceptions not enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53984 Tomalak Geret'kal changed: What|Removed |Added CC| |tom at kera dot name --- Comment #3 from Tomalak Geret'kal --- Another testcase was proposed under the following Stack Overflow question: http://stackoverflow.com/q/20371956/560648 The answer to that question was a link to this bug.
[Bug c++/86049] Array bindings are not const when initializer is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86049 Tomalak Geret'kal changed: What|Removed |Added CC| |tom at kera dot name --- Comment #3 from Tomalak Geret'kal --- I disagree and think that Clang is wrong. The top-level qualifiers of T (the type of One) should be "cv", and cv is "the cv-qualifiers in the decl-specifier-seq". The decl-specifier-seq is "auto", not "const auto". That "auto" will infer "const int" doesn't seem to be relevant. Discussion on https://stackoverflow.com/q/53726135/560648.
[Bug libstdc++/88802] New: std::hash not implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88802
Bug ID: 88802
Summary: std::hash not implemented
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at kera dot name
Target Milestone: ---
See https://stackoverflow.com/q/54147254/560648.
C++17 requires that std::hash be provided. MSVS does, but dev
libstdc++ doesn't (and neither does libc++). This seems to be the case on trunk
still.
#include
int main()
{
std::hash h;
return h(nullptr);
}
Result:
main.cpp: In function 'int main()':
main.cpp:4:31: error: use of deleted function
'std::hash::hash()'
std::hash h;
Expected result:
Good build and some return code.
[Bug libstdc++/88802] std::hash not implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88802 --- Comment #1 from Tomalak Geret'kal --- [unord.hash]/2 > Each specialization of hash is either enabled or disabled, as described > below. [ Note: Enabled specializations meet the Cpp17Hash requirements, and > disabled specializations do not. — end note ] Each header that declares the > template hash provides enabled specializations of hash for nullptr_t and all > cv-unqualified arithmetic, enumeration, and pointer types. For any type Key > for which neither the library nor the user provides an explicit or partial > specialization of the class template hash, hash is disabled. (Clang HEAD does support this, it turns out.)
[Bug libstdc++/88947] New: regex_match doesn't fail early when given a non-matching pattern with a start-of-input anchor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88947
Bug ID: 88947
Summary: regex_match doesn't fail early when given a
non-matching pattern with a start-of-input anchor
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at kera dot name
Target Milestone: ---
I first raised this on SO (https://stackoverflow.com/q/54237547/560648), on
which I have posted some benchmarks to back up the claim(s) below.
Take the following:
#include
int main()
{
static const size_t BufSize = 100;
char buf[BufSize] = {};
auto begin = std::cbegin(buf), end = std::cend(buf);
std::cmatch groups;
std::regex::flag_type flags = std::regex_constants::ECMAScript;
std::regex re("^what", flags);
std::regex_search(begin, end, groups, re);
}
This attempts to match the pattern "^what" against a block of 100 characters.
The match is not expected to succeed (in this case, the input is simply 100
'\0's, but the problem exists for any non-matching input).
However, I expect the match to fail as soon as the first character of input is
examined. By adjusting BufSize to increasingly large values, we observe that
the execution time increases also, suggesting that the regex engine is
examining the entire input even though the presence of the anchor "^"
guarantees that a match will never be found. It only needed to examine the
first character to know this. When BufSize reaches larger values like 100KB,
this becomes quite problematic.
It is clear from the implementation code
(https://github.com/gcc-mirror/gcc/blob/464ac146f6d2aaab847f653edde3ae84a8366c94/libstdc%2B%2B-v3/include/bits/regex_executor.tcc#L37-L54)
that there is simply no logic in place to "fail fast" or "fail early" in a case
like this: the only way a "no match" result is returned is after examining the
whole input, regardless of the pattern.
It is my opinion that this is a quality of implementation issue, and one that
only appears in C++ implementations of regular expressions. This problem is
common to libstdc++, libc++ and also Visual Studio's stdlib impl. (I am raising
bugs against all three.)
As a workaround I'm having to artificially select a prefix of the input data in
order to get a fast result -- in the example above, that could be:
auto begin = std::cbegin(buf), end = std::cbegin(buf)+4;
However, not all examples are so trivial (indeed, the example above would be
much better approached with a simple string prefix comparison) and the
workaround not always so easy. When the pattern is more complex, it is not
always easy to find the best number of characters to send to the regex engine,
and the resulting code not particularly elegant. It would be much better if the
engine could be given the whole input without having to worry about scale.
Hopefully my expectation isn't unreasonable; Safari's implementation of regex
behaves as I'd expect. That is, the time to return a "no match" result is
constant (and fast) given the JS equivalent of the above example.
Is it possible that the regex_match implementation could be given a little more
intelligence?
(Apologies that I am not sufficiently familiar with libstdc++ version history
to select an appropriate version number for this bug.)
[Bug libstdc++/88947] regex_match doesn't fail early when given a non-matching pattern with a start-of-input anchor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88947 --- Comment #4 from Tomalak Geret'kal --- To be honest I'd expect this in less trivial circumstances too. If, at a given stage of processing, the only possible paths towards a match all require a prefix that's already been ruled out, that should be an immediate return false. To the best of my knowledge this is commonly what happens in regex engines (though again libstdc++ is far from alone in the C++ world in not doing so!)
[Bug libstdc++/88947] regex_match doesn't fail early when given a non-matching pattern with a start-of-input anchor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88947 --- Comment #7 from Tomalak Geret'kal --- (In reply to Tim Shen from comment #5) > For the original test case, have you tried regex_match() with "what.*"? That behaves as I'd expect (http://quick-bench.com/AKdMnnhA03T1vwfN9sf53xlbD6s). > Do you have any non-trivial testcase in mind that is still unexpectedly slow > with regex_match()? The original real-world pattern that led to me discovering this was: /^[\x02-\x7f]\0..[\x01-\x0c]\0..\0\0/ Switching to regex_match() for that pattern also yields the expected result (http://quick-bench.com/g6lZj00gBswzvd-rjO7QwRE0Exg), so that's a good workaround here. But, adapting your earlier example to "(^abc|xyz)", this would require chaining a regex_match with a regex_search, which gets unwieldy quite quickly. Well, okay, I suppose in that example we could regex_match on "(?:(abc).*|.*(xyz).*)", but I really don't think we should have to rewrite patterns like this in order to get the behaviour that's common in other ecosystems' regex impls. So, although I'm open to being convinced otherwise, I still think we would reasonably expect regex_search to fail fast.
[Bug c/85525] New: Alignment Issue in AVX compiler intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85525 Bug ID: 85525 Summary: Alignment Issue in AVX compiler intrinsics Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tom at ritter dot vg CC: jacek at codeweavers dot com Target Milestone: --- I am using gcc 6.4.0 and MinGW to compile some code that uses AVX intrinsics for Windows. Specifically, this code: https://searchfox.org/mozilla-central/rev/36dec78aecc40539ecc8d78e91612e38810f963c/gfx/skia/skia/src/opts/SkOpts_hsw.cpp The crashing instruction is: vmovdqa ymmword ptr [rbp-10h],ymm0 However at this location, rbp is 0 % 0x20 and vmovdqa expects 0x20 alignment (and in the assembly offset by 0x10). We think there is a missing alignment sequence at the beginning the function (there is one for rbx, but not rbp). The full disassembly and details are at https://pastebin.mozilla.org/9083932
[Bug target/85525] Alignment Issue in AVX compiler intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85525 --- Comment #2 from Tom Ritter --- (In reply to Andrew Pinski from comment #1) > What exact target is this on? Sorry, this is x64 if that's what you mean?
[Bug target/85525] Alignment Issue in AVX compiler intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85525 --- Comment #4 from Tom Ritter --- Created attachment 44018 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44018&action=edit Preprocessed source file
[Bug target/85525] Alignment Issue in AVX compiler intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85525 --- Comment #5 from Tom Ritter --- ./x86_64-w64-mingw32-g++ -v Using built-in specs. COLLECT_GCC=./x86_64-w64-mingw32-g++ COLLECT_LTO_WRAPPER=/builds/worker/workspace/build/src/mingw32/bin/../libexec/gcc/x86_64-w64-mingw32/6.4.0/lto-wrapper Target: x86_64-w64-mingw32 Configured with: ../gcc-6.4.0/configure --prefix=/tmp/tmp.G8UuS5o8Pw/tools/mingw32 --target=x86_64-w64-mingw32 --with- gnu-ld --with-gnu-as --disable-multilib --enable-threads=posix Thread model: posix gcc version 6.4.0 (GCC) /builds/worker/workspace/build/src/mingw32/bin/x86_64-w64-mingw32-g++ -mwindows -o SkOpts_hsw.o -c -I/builds/worker/workspace/build/src/obj-firefox/dist/stl_wrappers -DDEBUG=1 -DSK_JUMPER_USE_ASSEMBLY=0 -DUNICODE -D_UNICODE -DSKIA_IMPLEMENTATION=1 -DSK_PDF_USE_SFNTLY=1 -DSK_CAN_USE_DLOPEN=0 -DSTATIC_EXPORTABLE_JS_API -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -I/builds/worker/workspace/build/src/gfx/skia -I/builds/worker/workspace/build/src/obj-firefox/gfx/skia -I/builds/worker/workspace/build/src/gfx/skia/skia/include/c -I/builds/worker/workspace/build/src/gfx/skia/skia/include/config -I/builds/worker/workspace/build/src/gfx/skia/skia/include/core -I/builds/worker/workspace/build/src/gfx/skia/skia/include/effects -I/builds/worker/workspace/build/src/gfx/skia/skia/include/gpu -I/builds/worker/workspace/build/src/gfx/skia/skia/include/pathops -I/builds/worker/workspace/build/src/gfx/skia/skia/include/ports -I/builds/worker/workspace/build/src/gfx/skia/skia/include/private -I/builds/worker/workspace/build/src/gfx/skia/skia/include/utils -I/builds/worker/workspace/build/src/gfx/skia/skia/include/utils/mac -I/builds/worker/workspace/build/src/gfx/skia/skia/include/views -I/builds/worker/workspace/build/src/gfx/skia/skia/src/core -I/builds/worker/workspace/build/src/gfx/skia/skia/src/gpu -I/builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/effects -I/builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/gl -I/builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/glsl -I/builds/worker/workspace/build/src/gfx/skia/skia/src/image -I/builds/worker/workspace/build/src/gfx/skia/skia/src/lazy -I/builds/worker/workspace/build/src/gfx/skia/skia/src/opts -I/builds/worker/workspace/build/src/gfx/skia/skia/src/sfnt -I/builds/worker/workspace/build/src/gfx/skia/skia/src/sksl -I/builds/worker/workspace/build/src/gfx/skia/skia/src/utils -I/builds/worker/workspace/build/src/gfx/skia/skia/src/utils/mac -I/builds/worker/workspace/build/src/gfx/skia/skia/src/utils/win -I/builds/worker/workspace/build/src/gfx/sfntly/cpp/src -I/builds/worker/workspace/build/src/obj-firefox/dist/include -I/builds/worker/workspace/build/src/obj-firefox/dist/include/nspr -I/builds/worker/workspace/build/src/obj-firefox/dist/include/nss -DMOZILLA_CLIENT -include /builds/worker/workspace/build/src/obj-firefox/mozilla-config.h -Wall -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wduplicated-cond -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=free-nonheap-object -Wno-unknown-pragmas -Wno-unused-function -Wno-conversion-null -Wno-switch -Wno-enum-compare -fno-sized-deallocation -fno-exceptions -fno-strict-aliasing -mms-bitfields -fno-keep-inline-dllexport -fno-rtti -ffunction-sections -fdata-sections -Wa,-mbig-obj -fno-exceptions -fno-math-errno -pthread -pipe -g -fno-omit-frame-pointer -Wno-deprecated-declarations -Wno-overloaded-virtual -Wno-shadow -Wno-sign-compare -Wno-unreachable-code -Wno-unused-function -Wno-logical-op -Wno-maybe-uninitialized -MD -MP -MF .deps/SkOpts_hsw.o.pp -mavx2 /builds/worker/workspace/build/src/gfx/skia/skia/src/opts/SkOpts_hsw.cpp (There is no compiler output.)
[Bug target/85525] Alignment Issue in AVX compiler intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85525 --- Comment #6 from Tom Ritter --- Created attachment 44020 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44020&action=edit Disassembly of affected function
[Bug target/85525] Alignment Issue in AVX compiler intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85525 --- Comment #7 from Tom Ritter --- I'm compiling some AVX code with MinGW+gcc. I'm afraid it's difficult to create a test case, but I think there's an alignment issue here. Registers at crash site: rbp is 0x00 % 20 > 0:000> r > rax=15ce306b rbx=00656930 rcx=1f1ba500 > rdx= rsi= rdi=00656440 > rip=072656fa rsp=00656bc0 rbp=00657060 > r8=1fc0f0a0 r9=0018 r10=1fc0f0a0 > r11=1f75bcff r12=00657c90 r13=000f > r14= r15= > iopl=0 nv up ei pl nz na po nc > cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010204 > xul!XRE_GetBootstrap+0x256380a: > `072656fa c5fd7f45f0 vmovdqa ymmword ptr [rbp-10h],ymm0 > ss:`00657050=17 Disassembly: vmovdqa expects 0x20 alignment but offset by 0x10: `072356fa c5fd7f45f0 vmovdqa ymmword ptr [rbp-10h],ymm0 I've attached the disassembly. The c++ code is attached and also at: https://searchfox.org/mozilla-central/rev/36dec78aecc40539ecc8d78e91612e38810f963c/gfx/skia/skia/src/opts/SkOpts_hsw.cpp There is a function; convolve_16_pixels that corresponds to xul!XRE_GetBootstrap+0x6676510 in the attached disassembly It was pointed out that `07235595 48c1e805shr rax,5 `07235599 48c1e005shl rax,5 `0723559d 4889c3 mov rbx,rax aligns rbx at the entry to the function, so it can safely do things like vmovdqa ymmword ptr [rbx+3E0h],ymm0 However rbp does not get the same alignment treatment, and operations offset from it may not be correctly aligned.
[Bug target/85525] Alignment Issue in AVX compiler intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85525 --- Comment #9 from Tom Ritter --- This may be related to: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53485 https://sourceforge.net/p/mingw-w64/bugs/304/
[Bug c++/88095] class nontype template parameter UDL string literals doesn't accepts deduction placeholder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88095 --- Comment #3 from Tom Honermann --- A patch for this issue has been submitted: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00150.html
[Bug driver/91130] [9 Regression] -MF clashes with -flto on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130 Tom Honermann changed: What|Removed |Added CC||tom at honermann dot net --- Comment #46 from Tom Honermann --- Fixed for 9.3 and 10.
[Bug c++/88095] class nontype template parameter UDL string literals doesn't accepts deduction placeholder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88095 Tom Honermann changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||9.2.1 Resolution|--- |FIXED Target Milestone|--- |9.3 Known to fail||9.1.0, 9.2.0 --- Comment #7 from Tom Honermann --- Fixed for 9.3 and 10.
[Bug c++/71125] [concepts] Spurious 'invalid reference to function concept error' issued when overloads are not all declared with the concept specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71125 --- Comment #5 from Tom Honermann --- (In reply to Andrew Sutton from comment #3) > Function concepts have some parsing issues related to TS-style terse > notation, overloading and variadic templates. In particular, there are > places where writing C forms a (possibly) syntactically valid placeholder > C as part of a functional cast expression, which leads to the error > you're seeing: you're incompletely instantiating a template-id that resolved > to the template with two parameters. I was going to argue that that explanation didn't explain why the reported diagnostic doesn't occur when the order of the overload declarations are swapped. However, I did a quick test and found that, indeed, the diagnostic is not issued for the swapped case in gcc 6.1.0, but is in gcc 6.3, 7.1, and later. It seems the lack of a diagnostic in that case was some other issue that has since been fixed. (In reply to Jonathan Wakely from comment #4) > I think the "conflicts with a previous declaration" diagnostic is > reasonable. Maybe "redeclared as a different kind of symbol" would also work. I agree the diagnostics for the C++20 case are appropriate. I don't have an opinion on whether it is worth trying to improve them further. > I'll recategorise it as a diagnostic enhancement and confirm it, but I think > closing it would also be fine. As the original reported, I'm ok with this being closed since the original issue isn't relevant for C++20 concepts. I don't recall the situation that caused me to trip over this issue in the first place. I suspect I was just playing around with the interaction between constexpr and concept functions.
[Bug c++/89923] printf format check and char8_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89923 --- Comment #2 from Tom Honermann --- I think my preferred fix to this is to introduce new length modifiers for the "%s" conversion specifier for all of char8_t, char16_t, and char32_t.
[Bug c++/89923] printf format check and char8_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89923
--- Comment #4 from Tom Honermann ---
(In reply to Florian Weimer from comment #3)
> But the precedent with wchar_t is that the type of the format string
> determines the type of the %s arguments. I'm not sure if that's a good
> precedent, but it's what we have today.
That matches Microsoft's documented behavior
(https://docs.microsoft.com/en-us/cpp/c-runtime-library/format-specification-syntax-printf-and-wprintf-functions?view=vs-2019),
but it runs contrary to the C standard (C11 7.29.2.1) and glibc behavior.
To be clear, the position I'm suggesting is that we add support for something
like these:
printf("%U8s", u8"text");
printf("%U8c", u8'x');
wprintf(L"%U8s", u8"text");
wprintf(L"%U8c", u8'x');
printf("%U16s", u"text");
printf("%U16c", u'x');
wprintf(L"%U16s", u"text");
wprintf(L"%U16c", u'x');
printf("%U32s", U"text");
printf("%U32c", U'x');
wprintf(L"%U32s", U"text");
wprintf(L"%U32c", U'x');
[Bug c++/89923] printf format check and char8_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89923 --- Comment #6 from Tom Honermann --- (In reply to jos...@codesourcery.com from comment #5) > We (GCC) don't control printf; I know, by "we" I meant the C and C++ standards community. > the format checking should match what the > actual libc supports. Agreed.
[Bug c++/88095] class nontype template parameter UDL string literals doesn't accepts deduction placeholder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88095 --- Comment #2 from Tom Honermann --- I confirmed that Jeff's patch, applied to gcc 9.1.0, suffices to address both Hana's test case and the code in the "Emulate C++17 u8 literals" section of P1423R2 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1423r2.html#emulate) if the declaration of operator <=> is commented out (since gcc doesn't yet support operator <=>).
[Bug c/39170] provide an option to silence -Wconversion warnings for bit-fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39170 --- Comment #12 from Tom Geocaris 2013-01-04 17:32:22 UTC --- Is there any resolution to this issue? We need to move to a more recent version of gcc, but are still stuck at gcc 4.2.4. I looked at gcc 4.7.2 but behavior is the same and I don't see an option to suppress these warnings.
[Bug rtl-optimization/69570] [6 Regression] if-conversion bug on i?86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69570 --- Comment #11 from Tom Hughes --- This is C++ so -fexcess-precision=standard is no help as that is C only. Likewise -ffloat-store is, as I understand it, not much help in real world code because you need to make sure that you force stores in order to trigger it? Using -mpc64 seems very scary as I believe it alters the global state of the program. So short of -mfpmath=sse I suspect the only solution is to replace the equality with a comparisin that allow some variation. I'll just slink off and go back to hating x87 FP math I think...
[Bug rtl-optimization/69570] [6 Regression] if-conversion bug on i?86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69570 --- Comment #14 from Tom Hughes --- Yes upstream took my fix to avoid the equality (https://github.com/mapnik/node-mapnik/pull/589) but have also now noticed that most of the FP can be one away with completely.
[Bug c++/69515] partial specialization of variable templates is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69515
Tom Honermann changed:
What|Removed |Added
CC||tom at honermann dot net
--- Comment #1 from Tom Honermann ---
I'm also experiencing this; gcc r234493.
$ cat t.cpp
template
constexpr bool b = false;
template
constexpr bool b = true;
int main() {
b;
b;
}
$ g++ -std=c++14 t.cpp -o t
/tmp/ccYIejpd.s: Assembler messages:
/tmp/ccYIejpd.s:27: Error: symbol `_ZL1b' is already defined
$ gcc --version
gcc (GCC) 6.0.0 20160327 (experimental)
...
[Bug c++/70095] [C++14] Link error on partially specialized variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70095
Tom Honermann changed:
What|Removed |Added
CC||tom at honermann dot net
--- Comment #2 from Tom Honermann ---
The change in comment 1 introduced a regression. The following test passes
with r234230, but fails with r234231:
$ cat t.cpp
template
constexpr bool b = false;
template
constexpr bool b = true;
int main() {
b;
b;
}
$ g++ -std=c++14 t.cpp -o t
/tmp/ccJTAQId.s: Assembler messages:
/tmp/ccJTAQId.s:27: Error: symbol `_ZL1b' is already defined
[Bug c++/69515] partial specialization of variable templates is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69515 --- Comment #2 from Tom Honermann --- (In reply to Tom Honermann from comment #1) Actually, the test case in comment 1 seems to be a different issue; its failure is a regression introduced in r234231 via bug 70095. As of r234231 (and up through at least r234502), the test case in comment 0 triggers an ICE. $ g++ -std=c++14 t.cpp -o t t.cpp:9:31: error: Two symbols with same comdat_group are not linked by the same_comdat_group list. auto&& b = foo>; ^ foo/3 (A foo) @0x7f6c0f987000 Type: variable definition analyzed Visibility: public weak comdat comdat_group:foo one_only previous sharing asm name: 2 References: Referring: b/1 (addr)_Z41__static_initialization_and_destruction_0ii/5 (addr) Availability: not-ready Varpool flags: foo/2 (A foo) @0x7f6c0f97cf80 Type: variable definition analyzed Visibility: public weak comdat comdat_group:foo one_only next sharing asm name: 3 References: Referring: a/0 (addr)_Z41__static_initialization_and_destruction_0ii/5 (addr) Availability: not-ready Varpool flags: t.cpp:9:31: internal compiler error: symtab_node::verify failed 0x928ee1 symtab_node::verify_symtab_nodes() ../../gcc-trunk/gcc/symtab.c:1219 0x93ba14 symtab_node::checking_verify_symtab_nodes() ../../gcc-trunk/gcc/cgraph.h:602 0x93ba14 symbol_table::compile() ../../gcc-trunk/gcc/cgraphunit.c:2380 0x93df87 symbol_table::compile() ../../gcc-trunk/gcc/cgraphunit.c:2536 0x93df87 symbol_table::finalize_compilation_unit() ../../gcc-trunk/gcc/cgraphunit.c:2562
[Bug c++/70862] [concepts] adding a concept-constrained version of a variable template causes multiple definition assembler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70862 Tom Honermann changed: What|Removed |Added CC||tom at honermann dot net --- Comment #2 from Tom Honermann --- This looks to be a duplicate of bug 70095.
[Bug c++/70037] [concepts] comdat group error and an ICE with a conceptified tuple implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70037 Tom Honermann changed: What|Removed |Added CC||tom at honermann dot net --- Comment #2 from Tom Honermann --- This error was also reported in bug 69515 comment 2.
[Bug c++/69515] partial specialization of variable templates is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69515 --- Comment #3 from Tom Honermann --- The error in comment 2 was also reported in bug 69364.
[Bug c++/71125] New: [concepts] Spurious 'invalid reference to function concept error' issued when overloads are not all declared with the concept specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71125
Bug ID: 71125
Summary: [concepts] Spurious 'invalid reference to function
concept error' issued when overloads are not all
declared with the concept specifier
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
I believe the following code is well-formed.
$ cat t.cpp
// This test case demonstrates a spurious reference to function concept error.
// The error is emitted when:
// 1: a constexpr function is declared without the concept specifier, and
// 2: an overload declared with the concept specifier follows, and
// 3: overload resolution of a function invocation in a requires clause of a
//following constrained function declaration selects the first declaration.
template
constexpr bool C1() { return true; }
template
concept bool C1() { return true; }
template
requires C1() // spurious error: invalid reference to function concept
‘template constexpr bool C1()’
void f1() {}
// Removing the unused overload avoids the error:
template
constexpr bool C2() { return true; }
template
requires C2() // Ok.
void f2() {}
// Swapping the order of the declarations avoids the error:
template
concept bool C3() { return true; }
template
constexpr bool C3() { return true; }
template
requires C3() // Ok.
void f3() {}
// Swapping the overload that is resolved avoids the error:
template
constexpr bool C4() { return true; }
template
concept bool C4() { return true; }
template
requires C4() // Ok.
void f4() {}
// Swapping which overload is declared with the concept specifier avoids the
error:
template
concept bool C5() { return true; }
template
constexpr bool C5() { return true; }
template
requires C5() // Ok.
void f5() {}
$ svn info # From my local svn gcc repo.
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236239
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236238
Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016)
$ g++ --version
g++ (GCC) 7.0.0 20160514 (experimental)
...
$ g++ -c -fconcepts -std=c++1z t.cpp
t.cpp:13:12: error: invalid reference to function concept ‘template constexpr bool C1()’
requires C1() // spurious error: invalid reference to function concept
‘template constexpr bool C1()’
^
[Bug c++/71126] New: [concepts] ICE on ill-formed code declaring a variable with a non-type concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71126 Bug ID: 71126 Summary: [concepts] ICE on ill-formed code declaring a variable with a non-type concept Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tom at honermann dot net CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org Target Milestone: --- The following ill-formed code triggers an ICE in gcc r236239. $ cat t.cpp template concept bool C = N==1; C c = 1; $ svn info Path: . Working Copy Root Path: /home/tom/src/gcc-trunk URL: svn://gcc.gnu.org/svn/gcc/trunk Relative URL: ^/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 236239 Node Kind: directory Schedule: normal Last Changed Author: uros Last Changed Rev: 236238 Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016) $ g++ --version g++ (GCC) 7.0.0 20160514 (experimental) ... $ g++ -c -std=c++1z -fconcepts t.cpp t.cpp:3:7: internal compiler error: tree check: expected tree_vec, have error_mark in tsubst, at cp/pt.c:12954 C c = 1; ^ 0xff7e0c tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc-trunk/gcc/tree.c:9753 0x6bd076 tree_check(tree_node*, char const*, int, char const*, tree_code) ../../gcc-trunk/gcc/tree.h:3025 0x6bd076 tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc-trunk/gcc/cp/pt.c:12954 0x6b1a78 tsubst_copy ../../gcc-trunk/gcc/cp/pt.c:14077 0x6b787a tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc-trunk/gcc/cp/pt.c:17161 0x6b720b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc-trunk/gcc/cp/pt.c:16176 0x6abfee tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc-trunk/gcc/cp/pt.c:15800 0x889617 satisfy_predicate_constraint ../../gcc-trunk/gcc/cp/constraint.cc:1768 0x889617 satisfy_constraint_1 ../../gcc-trunk/gcc/cp/constraint.cc:1975 0x88a416 satisfy_constraint ../../gcc-trunk/gcc/cp/constraint.cc:2026 0x6deb08 lookup_and_finish_template_variable ../../gcc-trunk/gcc/cp/pt.c:8715 0x6b87c2 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc-trunk/gcc/cp/pt.c:15991 0x6abfee tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc-trunk/gcc/cp/pt.c:15800 0x889617 satisfy_predicate_constraint ../../gcc-trunk/gcc/cp/constraint.cc:1768 0x889617 satisfy_constraint_1 ../../gcc-trunk/gcc/cp/constraint.cc:1975 0x88a416 satisfy_constraint ../../gcc-trunk/gcc/cp/constraint.cc:2026 0x88b694 constraints_satisfied_p(tree_node*, tree_node*) ../../gcc-trunk/gcc/cp/constraint.cc:2146 0x6eaf3a do_auto_deduction(tree_node*, tree_node*, tree_node*, int, auto_deduction_context) ../../gcc-trunk/gcc/cp/pt.c:24065 0x67a9bb cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int) ../../gcc-trunk/gcc/cp/decl.c:6606 0x77e62f cp_parser_init_declarator ../../gcc-trunk/gcc/cp/parser.c:18694 ...
[Bug c++/71127] New: [concepts] ICE on ill-formed code declaring a variable with a template concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71127 Bug ID: 71127 Summary: [concepts] ICE on ill-formed code declaring a variable with a template concept Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tom at honermann dot net CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org Target Milestone: --- The following ill-formed code triggers an ICE in gcc r236239. $ cat t.cpp template class T> concept bool C = T::value; C c = 1; $ svn info Path: . Working Copy Root Path: /home/tom/src/gcc-trunk URL: svn://gcc.gnu.org/svn/gcc/trunk Relative URL: ^/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 236239 Node Kind: directory Schedule: normal Last Changed Author: uros Last Changed Rev: 236238 Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016) $ g++ --version g++ (GCC) 7.0.0 20160514 (experimental) ... $ g++ -c -std=c++1z -fconcepts t.cpp t.cpp:3:7: internal compiler error: tree check: expected tree_vec, have error_mark in tsubst, at cp/pt.c:12954 C c = 1; ^ 0xff7e0c tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc-trunk/gcc/tree.c:9753 0x6bd076 tree_check(tree_node*, char const*, int, char const*, tree_code) ../../gcc-trunk/gcc/tree.h:3025 0x6bd076 tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc-trunk/gcc/cp/pt.c:12954 0x6b50aa tsubst_qualified_id ../../gcc-trunk/gcc/cp/pt.c:13728 0x6b70a3 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc-trunk/gcc/cp/pt.c:16204 0x6abfee tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc-trunk/gcc/cp/pt.c:15800 0x889617 satisfy_predicate_constraint ../../gcc-trunk/gcc/cp/constraint.cc:1768 0x889617 satisfy_constraint_1 ../../gcc-trunk/gcc/cp/constraint.cc:1975 0x88a416 satisfy_constraint ../../gcc-trunk/gcc/cp/constraint.cc:2026 0x6deb08 lookup_and_finish_template_variable ../../gcc-trunk/gcc/cp/pt.c:8715 0x6b87c2 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc-trunk/gcc/cp/pt.c:15991 0x6abfee tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc-trunk/gcc/cp/pt.c:15800 0x889617 satisfy_predicate_constraint ../../gcc-trunk/gcc/cp/constraint.cc:1768 0x889617 satisfy_constraint_1 ../../gcc-trunk/gcc/cp/constraint.cc:1975 0x88a416 satisfy_constraint ../../gcc-trunk/gcc/cp/constraint.cc:2026 0x88b694 constraints_satisfied_p(tree_node*, tree_node*) ../../gcc-trunk/gcc/cp/constraint.cc:2146 0x6eaf3a do_auto_deduction(tree_node*, tree_node*, tree_node*, int, auto_deduction_context) ../../gcc-trunk/gcc/cp/pt.c:24065 0x67a9bb cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int) ../../gcc-trunk/gcc/cp/decl.c:6606 0x77e62f cp_parser_init_declarator ../../gcc-trunk/gcc/cp/parser.c:18694 0x77ed29 cp_parser_simple_declaration ../../gcc-trunk/gcc/cp/parser.c:12378 ...
[Bug c++/71128] New: [concepts] ICE on ill-formed explicit instantiation of a function concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71128
Bug ID: 71128
Summary: [concepts] ICE on ill-formed explicit instantiation of
a function concept
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
The following ill-formed code triggers an ICE in gcc r236239.
$ cat t.cpp
template
concept bool C() { return true; }
template bool C(); // expected error: attempt to explicitly instantiate
// a function concept.
$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236239
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236238
Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016)
$ g++ --version
g++ (GCC) 7.0.0 20160514 (experimental)
...
$ g++ -c -std=c++1z -fconcepts t.cpp
t.cpp:3:22: internal compiler error: in instantiate_decl, at cp/pt.c:21666
template bool C();
^
0x6a8c51 instantiate_decl(tree_node*, int, bool)
../../gcc-trunk/gcc/cp/pt.c:21666
0x77751d cp_parser_explicit_instantiation
../../gcc-trunk/gcc/cp/parser.c:15648
0x788c79 cp_parser_declaration
../../gcc-trunk/gcc/cp/parser.c:12095
0x7874b6 cp_parser_declaration_seq_opt
../../gcc-trunk/gcc/cp/parser.c:12022
0x7877c4 cp_parser_translation_unit
../../gcc-trunk/gcc/cp/parser.c:4324
0x7877c4 c_parse_file()
../../gcc-trunk/gcc/cp/parser.c:37475
0x8e7e42 c_common_parse_file()
../../gcc-trunk/gcc/c-family/c-opts.c:1064
...
[Bug c++/71129] New: [concepts] ICE on ill-formed explicit instantiation of a variable concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71129 Bug ID: 71129 Summary: [concepts] ICE on ill-formed explicit instantiation of a variable concept Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tom at honermann dot net CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org Target Milestone: --- The following ill-formed code triggers an ICE in gcc r236239. $ cat t.cpp template concept bool C = true; template bool C; $ svn info Path: . Working Copy Root Path: /home/tom/src/gcc-trunk URL: svn://gcc.gnu.org/svn/gcc/trunk Relative URL: ^/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 236239 Node Kind: directory Schedule: normal Last Changed Author: uros Last Changed Rev: 236238 Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016) $ g++ --version g++ (GCC) 7.0.0 20160514 (experimental) ... $ g++ -c -std=c++1z -fconcepts t.cpp t.cpp:3:15: internal compiler error: in instantiate_decl, at cp/pt.c:21666 template bool C; ^~ 0x6a8c51 instantiate_decl(tree_node*, int, bool) ../../gcc-trunk/gcc/cp/pt.c:21666 0x77751d cp_parser_explicit_instantiation ../../gcc-trunk/gcc/cp/parser.c:15648 0x788c79 cp_parser_declaration ../../gcc-trunk/gcc/cp/parser.c:12095 0x7874b6 cp_parser_declaration_seq_opt ../../gcc-trunk/gcc/cp/parser.c:12022 0x7877c4 cp_parser_translation_unit ../../gcc-trunk/gcc/cp/parser.c:4324 0x7877c4 c_parse_file() ../../gcc-trunk/gcc/cp/parser.c:37475 0x8e7e42 c_common_parse_file() ../../gcc-trunk/gcc/c-family/c-opts.c:1064 ...
[Bug c++/71130] New: [concepts] Ill-formed code declaring a variable with a non-type concept not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71130 Bug ID: 71130 Summary: [concepts] Ill-formed code declaring a variable with a non-type concept not rejected Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tom at honermann dot net CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org Target Milestone: --- The following ill-formed code is not rejected as it should be in gcc r236239. This test case is similar to the one that triggers an ICE in bug 71126. $ cat t.cpp template concept bool C = true; C c = 1; $ svn info Path: . Working Copy Root Path: /home/tom/src/gcc-trunk URL: svn://gcc.gnu.org/svn/gcc/trunk Relative URL: ^/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 236239 Node Kind: directory Schedule: normal Last Changed Author: uros Last Changed Rev: 236238 Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016) $ g++ --version g++ (GCC) 7.0.0 20160514 (experimental) ... $ g++ -c -std=c++1z -fconcepts t.cpp; echo $? 0
[Bug c++/71131] New: [concepts] Ill-formed code declaring a variable with a template concept not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71131 Bug ID: 71131 Summary: [concepts] Ill-formed code declaring a variable with a template concept not rejected Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tom at honermann dot net CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org Target Milestone: --- The following ill-formed code is not rejected as it should be in gcc r236239. This test case is similar to the one that triggers an ICE in bug 71127. $ cat t.cpp template class T> concept bool C = true; C c = 1; $ svn info Path: . Working Copy Root Path: /home/tom/src/gcc-trunk URL: svn://gcc.gnu.org/svn/gcc/trunk Relative URL: ^/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 236239 Node Kind: directory Schedule: normal Last Changed Author: uros Last Changed Rev: 236238 Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016) $ g++ --version g++ (GCC) 7.0.0 20160514 (experimental) ... $ g++ -c -std=c++1z -fconcepts t.cpp; echo $? 0
[Bug c++/71136] New: [concepts] Spurious 'converting overloaded function is ambiguous' error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71136
Bug ID: 71136
Summary: [concepts] Spurious 'converting overloaded function is
ambiguous' error.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
I believe the following test case is well-formed, but it is rejected by gcc
r236238.
$ cat t.cpp
template
struct is_same {};
template
struct is_same { using type = T; };
// Concept imposes a same-type-as-int constraint.
template
concept bool C = requires { typename is_same::type; };
template
constexpr int f() { return 0; } // #1, unconstrained overload.
template
constexpr int f() { return 1; } // #2, constrained overload.
// Obtaining a function pointer to #1 is ok:
constexpr auto x0 = f;// Ok, overload selects #1
static_assert(x0() == 0); // Ok.
// Invoking #2 is ok:
constexpr auto x1 = f(); // Ok, overload selects #2
static_assert(x1 == 1); // Ok.
// Obtaining a function pointer to #2 fails:
constexpr auto x2 = f; // spurious error: 'converting overloaded
// function is ambiguous'; should select #2.
static_assert(x2() == 1);
$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236239
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236238
Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016)
$ g++ --version
g++ (GCC) 7.0.0 20160514 (experimental)
...
$ g++ -c -std=c++1z -fconcepts t.cpp
t.cpp:24:21: error: converting overloaded function ‘f’ to type ‘int (*
const)()’ is ambiguous
constexpr auto x2 = f; // spurious error: 'converting overloaded
^~
t.cpp:11:15: note: candidates are: constexpr int f() [with U = int]
constexpr int f() { return 0; } // #1, unconstrained overload.
^
t.cpp:13:15: note: constexpr int f() [with U = int]
constexpr int f() { return 1; } // #2, constrained overload.
^
t.cpp:26:1: error: non-constant condition for static assertion
static_assert(x2() == 1);
^
[Bug c++/71137] New: [concepts] Spurious 'symbol is already defined' error issued when declaring a constrained non-template function overload.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71137
Bug ID: 71137
Summary: [concepts] Spurious 'symbol is already defined' error
issued when declaring a constrained non-template
function overload.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
I believe the following test case is well-formed; the Concepts TS has similar
examples (§ 13.4p4). However, compiling this code results in a duplicate
definition error in gcc r236238.
$ cat t.cpp
void f() {}
void f() requires true {}
$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236239
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236238
Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016)
$ g++ --version
g++ (GCC) 7.0.0 20160514 (experimental)
...
$ g++ -c -std=c++1z -fconcepts t.cpp
/tmp/ccONCRCJ.s: Assembler messages:
/tmp/ccONCRCJ.s:22: Error: symbol `_Z1fv' is already defined
[Bug c++/71138] New: [concepts] ill-formed non-constant expression use in nested requirement produces duplicated diagnostics with poor source locations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71138
Bug ID: 71138
Summary: [concepts] ill-formed non-constant expression use in
nested requirement produces duplicated diagnostics
with poor source locations
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
The following test case is ill-formed and gcc r236238 correctly rejects it.
However, duplicate diagnostic are issued and the diagnostics fail to identify
the problematic source code.
The test case contains two instances of constraint satisfaction failures
labeled #1 and #2. The first occurs in a static_assert and produces a single
error message. The second occurs in overload resolution and produces three
duplicate error messages.
None of the diagnostics produce identify the problematic source code annotated
in the test case.
$ cat t.cpp
template
constexpr bool p(T) { return true; }
template
concept bool C = requires(T t) {
requires p(t); // An error should be reported here.
};
static_assert(C); // #1: error: ‘t’ is not a constant expression
template
int f(T) { return 1; }
auto x = f(1); // #2: (3x) error: ‘t’ is not a constant expression
$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236239
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236238
Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016)
$ g++ --version
g++ (GCC) 7.0.0 20160514 (experimental)
...
$ g++ -c -std=c++1z -fconcepts t.cpp
t.cpp:8:15: error: ‘t’ is not a constant expression
static_assert(C); // #1: error: ‘t’ is not a constant expression
^~
t.cpp:12:13: error: ‘t’ is not a constant expression
auto x = f(1); // #2: (3x) error: ‘t’ is not a constant expression
^
t.cpp:12:13: error: ‘t’ is not a constant expression
t.cpp:12:13: error: cannot call function ‘int f(T) [with T = int]’
t.cpp:11:5: note: constraints not satisfied
int f(T) { return 1; }
^
t.cpp:12:13: error: ‘t’ is not a constant expression
auto x = f(1); // #2: (3x) error: ‘t’ is not a constant expression
^
t.cpp:11:5: note: concept ‘C’ was not satisfied
int f(T) { return 1; }
^
[Bug c++/71139] New: [concepts] ill-formed compound-requirement lacking a semicolon not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71139
Bug ID: 71139
Summary: [concepts] ill-formed compound-requirement lacking a
semicolon not rejected
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
The following ill-formed code is not rejected by gcc r236238. According to the
Concepts TS § 5.1.4.3, the compound-requirement must include a terminating
semicolon.
$ cat a.cpp
template
concept bool C = requires(T t) {
{ +t }
}; // expected error: expected ‘;’ before ‘}’ token
static_assert(C);
$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236239
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236238
Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016)
$ g++ --version
g++ (GCC) 7.0.0 20160514 (experimental)
...
$ g++ -c -std=c++1z -fconcepts a.cpp; echo $?
0
[Bug c++/71140] New: [concepts] ill-formed nested-requirement lacking a semicolon not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71140
Bug ID: 71140
Summary: [concepts] ill-formed nested-requirement lacking a
semicolon not rejected
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
The following ill-formed code is not rejected by gcc r236238. According to the
Concepts TS § 5.1.4.4, the nested-requirement must include a terminating
semicolon.
$ cat a.cpp
template
concept bool C = requires(T t) {
requires true
}; // expected error: expected ‘;’ before ‘}’ token
static_assert(C);
$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236239
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236238
Last Changed Date: 2016-05-14 05:07:13 -0400 (Sat, 14 May 2016)
$ g++ --version
g++ (GCC) 7.0.0 20160514 (experimental)
...
$ g++ -c -std=c++1z -fconcepts a.cpp; echo $?
0
[Bug c++/71141] New: [concepts] Example variadic concept code in the Concepts TS 14.1p9.4 rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71141 Bug ID: 71141 Summary: [concepts] Example variadic concept code in the Concepts TS 14.1p9.4 rejected Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tom at honermann dot net CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org Target Milestone: --- The following test case is taken from example code in the Concepts TS § 14.1 p9.4. gcc r236238 rejects this code. I presume the code is intended to be well-formed; if not, then the Concepts TS should be updated. $ cat t1.cpp template concept bool C4 = true; template void f5(); $ g++ -c -std=c++1z -fconcepts t1.cpp t1.cpp:2:14: error: variadic constraint introduced without ‘...’ before ‘>’ token template void f5(); ^ The example is accepted if the constrained function is re-written with a requires clause: $ cat t2.cpp template concept bool C4 = true; template requires C4 void f5(); $ g++ -c -std=c++1z -fconcepts t2.cpp; echo $? 0 An error is similarly produced when using a variadic non-type concept: $ cat t3.cpp template concept bool C5 = true; template void f7(); $ g++ -c -std=c++1z -fconcepts t3.cpp t3.cpp:2:14: error: variadic constraint introduced without ‘...’ before ‘>’ token template void f7(); ^
[Bug c++/71141] [concepts] Example variadic concept code in the Concepts TS 14.1p9.4 rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71141 --- Comment #1 from Tom Honermann --- If it is decided that this code is well-formed, then I think the declaration of f7() in t3.cpp should be added to the example in the Concepts TS.
[Bug c++/69515] partial specialization of variable templates is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69515 --- Comment #4 from Tom Honermann --- (In reply to Tom Honermann from comment #3) > The error in comment 2 was also reported in bug 69364. I don't know where I got that bug number from. That should have been: The error in comment 2 was also reported in bug 70037.
[Bug c++/70862] [concepts] adding a concept-constrained version of a variable template causes multiple definition assembler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70862 --- Comment #4 from Tom Honermann --- (In reply to ryan.burn from comment #3) > It's a different bug. The test case from 70095 compiles fine with the trunk > from 20160428, but the above example won't. The example in bug 70095 comment 2 still fails the same way. That example is known to be a regression caused by the change noted in bug 70095 comment 1 that intended to fix the example in bug 70095 comment 0. That change also affected the behavior of the example in bug 69515 (but didn't fix it). I don't know how related these issues are.
[Bug c++/71221] New: [concepts] ICE in tsubst_pack_expansion when expanding a sizeof... expression in a requires clause of a member function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71221
Bug ID: 71221
Summary: [concepts] ICE in tsubst_pack_expansion when expanding
a sizeof... expression in a requires clause of a
member function template
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
The following test case demonstrates an internal compiler error that occurs
with gcc 7.0.0 (r236423) when expanding a sizeof... expression in a requires
clause of a member function template.
$ cat t.cpp
template
struct int_sequence {};
template
struct S {
template
requires sizeof...(Is) == N
int mf1(int_sequence);
void mf2() {
mf1(int_sequence<>{});
}
};
$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236427
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236423
Last Changed Date: 2016-05-18 15:15:22 -0400 (Wed, 18 May 2016)
$ g++ --version
g++ (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010
...
$ g++ -c -std=c++1z -fconcepts t.cpp
t.cpp: In member function ‘void S::mf2()’:
t.cpp:6:20: internal compiler error: in tsubst_pack_expansion, at cp/pt.c:10967
requires sizeof...(Is) == N
^~~
0x6c758f tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
../../gcc-trunk/gcc/cp/pt.c:10967
0x6b190b tsubst_copy
../../gcc-trunk/gcc/cp/pt.c:14131
0x6b525a tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-trunk/gcc/cp/pt.c:17161
0x6b4beb tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-trunk/gcc/cp/pt.c:16176
0x6a99ee tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-trunk/gcc/cp/pt.c:15800
0x889a67 satisfy_predicate_constraint
../../gcc-trunk/gcc/cp/constraint.cc:1768
0x889a67 satisfy_constraint_1
../../gcc-trunk/gcc/cp/constraint.cc:1975
0x88a866 satisfy_constraint
../../gcc-trunk/gcc/cp/constraint.cc:2026
0x88a9bc constraints_satisfied_p(tree_node*)
../../gcc-trunk/gcc/cp/constraint.cc:2133
0x64807c add_function_candidate
../../gcc-trunk/gcc/cp/call.c:2013
0x648d9c add_template_candidate_real
../../gcc-trunk/gcc/cp/call.c:3146
0x649693 add_template_candidate
../../gcc-trunk/gcc/cp/call.c:3188
0x649693 add_candidates
../../gcc-trunk/gcc/cp/call.c:5361
0x649f2f build_new_method_call_1
../../gcc-trunk/gcc/cp/call.c:8313
0x649f2f build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc-trunk/gcc/cp/call.c:8512
0x7610f2 cp_parser_postfix_expression
../../gcc-trunk/gcc/cp/parser.c:6875
0x75ebdc cp_parser_unary_expression
../../gcc-trunk/gcc/cp/parser.c:7986
0x768db7 cp_parser_cast_expression
../../gcc-trunk/gcc/cp/parser.c:8663
0x7693a3 cp_parser_binary_expression
../../gcc-trunk/gcc/cp/parser.c:8764
0x769c94 cp_parser_assignment_expression
../../gcc-trunk/gcc/cp/parser.c:9051
...
[Bug c++/71222] New: [concepts] ill-formed code taking the address of a function concept not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71222
Bug ID: 71222
Summary: [concepts] ill-formed code taking the address of a
function concept not rejected
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
I believe the following code is ill-formed though I was unable to find
normative text in N4553 that explicitly makes it such. The following
non-normative note in § 7.1.7p5 [dcl.spec.concept] suggests the intent for this
code to be ill-formed:
[Note: Return type deduction requires the instantiation of the function
definition, but concept definitions are not instantiated; they are normalized
(14.10.2). — end note]
gcc 7.0.0 (r236423) currently accepts this code, though a link error occurs
when linking an executable due to the reference to the uninstantiated FC
function concept. Note that directly invoking the function concept would
produce no errors since the result is evaluated at compile time; only taking
the address and later attempting to invoke the function is ill-formed.
$ cat t.cpp
template
concept bool FC() { return true; }
int main() {
auto fc = &FC;
fc();
}
$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236427
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236423
Last Changed Date: 2016-05-18 15:15:22 -0400 (Wed, 18 May 2016)
$ g++ --version
g++ (GCC) 7.0.0 20160518 (experimental)
...
$ g++ -c -std=c++1z -fconcepts t.cpp; echo $?
0
$ g++ -std=c++1z -fconcepts t.o -o t
t.o: In function `main':
t.cpp:(.text+0xc): undefined reference to `bool FC()'
collect2: error: ld returned 1 exit status
[Bug c++/71221] [concepts] ICE in tsubst_pack_expansion when expanding a sizeof... expression in a requires clause of a member function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71221 --- Comment #1 from Tom Honermann --- (In reply to Tom Honermann from comment #0) > $ g++ --version > g++ (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010 Oops, I ran the above in the wrong terminal session. The correct gcc version info is: $ g++ --version g++ (GCC) 7.0.0 20160518 (experimental) ...
[Bug other/61896] Wrong documentation for -finput-charset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61896
Tom Honermann changed:
What|Removed |Added
CC||tom at honermann dot net
--- Comment #1 from Tom Honermann ---
Created attachment 38565
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38565&action=edit
Source file with ill-formed UTF-8 code unit sequences
Gcc's incorrect documentation regarding the default input character set
continues to be a source of confusion. See the discussion on the C++
std-proposals list at the following link (search for 'locale').
https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/Draft$20proposal$20of$20file$20string/std-proposals/tKioR8OUiAw/85NCUmojBwAJ
The current gcc 6.1.0 documentation for -finput-charset can be found here:
https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/Preprocessor-Options.html#Preprocessor-Options
The relevant text is:
-finput-charset=charset
Set the input character set, used for translation from the character set of
the input file to the source character set used by GCC. If the locale does
not specify, or GCC cannot get this information from the locale, the
default is UTF-8. This can be overridden by either the locale or this
command-line option. Currently the command-line option takes precedence if
there's a conflict. charset can be any encoding supported by the system's
iconv library routine.
The patch proposed in attachment 33179 in comment 0 is an improvement in that
it removes the incorrect references to use of the current locale in determining
the input character set. However, the proposed documentation is still
incorrect, or at least imprecise, with regard to use of UTF-8 as the default
input character set since gcc does not reject (or even emit a warning for)
ill-formed UTF-8 text.
An example follows. The attached test code (attached to prevent mutation of
the contents) contains ill-formed UTF-8 code unit sequences. Compilation with
gcc 6.1.0 (on a Linux system) succeeds despite the ill-formed input.
# To demonstrate that the text is ill-formed:
$ iconv -f utf-8 -t utf-8 t.cpp
#include
int main()
{
printf("narrow string: (well-formed UTF-8)\n");
for (unsigned char c : "£") { // 0xC2 0xA3
printf(" 0x%X\n", (unsigned int)c);
}
printf("narrow string: (ill-formed UTF-8)\n");
for (unsigned char c : "iconv: illegal input sequence at position 261
$ g++ --version
g++ (GCC) 6.1.0
...
$ g++ -Wall -Wextra -pedantic t.cpp -o t; echo $?
0
$ ./t
narrow string: (well-formed UTF-8)
0xC2
0xA3
0x0
narrow string: (ill-formed UTF-8)
0xA3
0x0
narrow string (hex escape):
0xA3
0x0
UTF-8 string: (well-formed UTF-8)
0xC2
0xA3
0x0
UTF-8 string: (ill-formed UTF-8)
0xA3
0x0
UTF-8 string (hex escape):
0xA3
0x0
As shown above, ill-formed code unit sequences are passed through without being
transcoded to the execution character set (I would expect an error or
translation to a replacement character for the ill-formed sequences).
Note that validation is performed if a non-utf-8 execution character set is
specified.
$ g++ -Wall -Wextra -pedantic -fexec-charset=iso8859-1 t.cpp -o t
t.cpp: In function ‘int main()’:
t.cpp:9:28: error: converting to execution character set: Invalid or incomplete
multibyte or wide character
for (unsigned char c : "�") { // 0xA3
^~~
I propose the documentation be updated to reflect this behavior:
-finput-charset=charset
Set the input character set, used for translation from the character set of
the input file to the source character set used by GCC. The default input
character set is UTF-8. charset can be any encoding supported by the
system's iconv library routine. If the input character set matches the
execution character set, then ill-formed code unit sequences are passed
through without validation or translation. Otherwise, ill-formed code unit
sequences will result in an error during transcoding to the execution
character set.
[Bug c++/69515] partial specialization of variable templates is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69515 --- Comment #6 from Tom Honermann --- (In reply to Jason Merrill from comment #5) > PR c++/60095 - partial specialization of variable templates I believe this was intended to refer to PR c++/70095.
[Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
Tom Honermann changed:
What|Removed |Added
CC||tom at honermann dot net
--- Comment #27 from Tom Honermann ---
We got bit by this warning recently. We compile with -Werror and, without an
option to suppress warnings in the following code, gcc rejects it. We think
this code should be accepted without a warning given the constant expressions
involved.
Clang does not issue a warning for this code. However, if an assignment to the
bit-field from a literal '2' (cast to E) is added, then Clang warns on the
assignment itself (as opposed to on the bit-field declaration). This seems
like a more useful approach.
$ cat t.cpp
enum E : unsigned char {
e0 = 0,
e1 = 1
};
struct S {
E e : 1;
};
void f(S s) {
s.e = e0;
s.e = e1;
s.e = (E)0;
s.e = (E)1;
};
$ g++ --version
g++ (GCC) 6.1.1 20160531
...
$ g++ -c -std=c++11 -Werror t.cpp
t.cpp:6:11: error: ‘S::e’ is too small to hold all values of ‘enum E’ [-Werror]
E e : 1;
^
cc1plus: all warnings being treated as errors
[Bug c++/71543] New: [concepts] ICE on ill-formed declaration of a parameter with a constrained-type-specifier in a requires expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71543
Bug ID: 71543
Summary: [concepts] ICE on ill-formed declaration of a
parameter with a constrained-type-specifier in a
requires expression
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
The following ill-formed code triggers an ICE in gcc trunk r236947. The code
is ill-formed because constrained-type-specifiers are not permitted to declare
parameters in requires expressions.
$ cat t.cpp
template
concept bool C1 = true;
template
concept bool C2 = requires(C1 c1) {};
$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236947
Node Kind: directory
Schedule: normal
Last Changed Author: jason
Last Changed Rev: 236947
Last Changed Date: 2016-05-31 15:49:22 -0400 (Tue, 31 May 2016)
$ gcc --version
gcc (GCC) 7.0.0 20160531 (experimental)
...
$ g++ -c -std=c++1z -fconcepts t.cpp
t.cpp:4:28: internal compiler error: in synthesize_implicit_template_parm, at
cp/parser.c:37843
concept bool C2 = requires(C1 c1) {};
^~
0x753793 synthesize_implicit_template_parm
../../gcc-trunk/gcc/cp/parser.c:37843
0x7539cc cp_parser_maybe_constrained_type_specifier
../../gcc-trunk/gcc/cp/parser.c:16463
0x753af8 cp_parser_nonclass_name
../../gcc-trunk/gcc/cp/parser.c:16541
0x761d41 cp_parser_type_name
../../gcc-trunk/gcc/cp/parser.c:16347
0x761d41 cp_parser_simple_type_specifier
../../gcc-trunk/gcc/cp/parser.c:16261
0x75dbdd cp_parser_type_specifier
../../gcc-trunk/gcc/cp/parser.c:15914
0x773494 cp_parser_decl_specifier_seq
../../gcc-trunk/gcc/cp/parser.c:12758
0x775159 cp_parser_parameter_declaration
../../gcc-trunk/gcc/cp/parser.c:20448
0x7759a4 cp_parser_parameter_declaration_list
../../gcc-trunk/gcc/cp/parser.c:20263
0x775e44 cp_parser_parameter_declaration_clause
../../gcc-trunk/gcc/cp/parser.c:20184
0x7592db cp_parser_requirement_parameter_list
../../gcc-trunk/gcc/cp/parser.c:24391
0x7592db cp_parser_requires_expression
../../gcc-trunk/gcc/cp/parser.c:24362
0x7592db cp_parser_primary_expression
../../gcc-trunk/gcc/cp/parser.c:5098
0x762775 cp_parser_postfix_expression
../../gcc-trunk/gcc/cp/parser.c:6688
0x760b5c cp_parser_unary_expression
../../gcc-trunk/gcc/cp/parser.c:7986
0x76ad47 cp_parser_cast_expression
../../gcc-trunk/gcc/cp/parser.c:8663
0x76b333 cp_parser_binary_expression
../../gcc-trunk/gcc/cp/parser.c:8764
0x76bc24 cp_parser_assignment_expression
../../gcc-trunk/gcc/cp/parser.c:9051
0x76c06a cp_parser_constant_expression
../../gcc-trunk/gcc/cp/parser.c:9321
0x76c8c4 cp_parser_initializer_clause
../../gcc-trunk/gcc/cp/parser.c:20837
...
[Bug c++/80746] New: [concepts] ICE evaluating constraints for concepts with dependent template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80746
Bug ID: 80746
Summary: [concepts] ICE evaluating constraints for concepts
with dependent template parameters
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
Target Milestone: ---
gcc 6.2/7.0/trunk reports an ICE when checking constraints involving concepts
defined with dependent template parameters:
$ cat t.cpp
template
concept bool C = true;
template T> class ct {};
struct S {
using type = int;
};
template class ct;
$ g++ --version
g++ (GCC) 8.0.0 20170513 (experimental)
...
$ g++ -c -fconcepts t.cpp
t.cpp:3:13: internal compiler error: in tsubst, at cp/pt.c:13471
template T> class ct {};
^
0x5dc61a tsubst(tree_node*, tree_node*, int, tree_node*)
../../source/gcc/cp/pt.c:13471
0x5daf5e tsubst(tree_node*, tree_node*, int, tree_node*)
../../source/gcc/cp/pt.c:13895
0x5e6720 convert_template_argument
../../source/gcc/cp/pt.c:7623
0x5e7a10 coerce_template_parms
../../source/gcc/cp/pt.c:8098
0x6de12a resolve_variable_concept_check(tree_node*)
../../source/gcc/cp/constraint.cc:304
0x6de1d4 deduce_constrained_parameter(tree_node*, tree_node*&, tree_node*&)
../../source/gcc/cp/constraint.cc:329
0x61f41e cp_parser_maybe_constrained_type_specifier
../../source/gcc/cp/parser.c:17097
0x6333bd cp_parser_maybe_partial_concept_id
../../source/gcc/cp/parser.c:17154
0x6333bd cp_parser_template_id
../../source/gcc/cp/parser.c:15513
0x63362f cp_parser_class_name
../../source/gcc/cp/parser.c:21974
0x63dcc7 cp_parser_qualifying_entity
../../source/gcc/cp/parser.c:6287
0x63dcc7 cp_parser_nested_name_specifier_opt
../../source/gcc/cp/parser.c:5973
0x62a650 cp_parser_constructor_declarator_p
../../source/gcc/cp/parser.c:25986
0x62a650 cp_parser_decl_specifier_seq
../../source/gcc/cp/parser.c:13332
0x6448b5 cp_parser_parameter_declaration
../../source/gcc/cp/parser.c:21204
0x645856 cp_parser_template_parameter
../../source/gcc/cp/parser.c:15133
0x645856 cp_parser_template_parameter_list
../../source/gcc/cp/parser.c:14722
0x64670b cp_parser_explicit_template_declaration
../../source/gcc/cp/parser.c:26580
0x64670b cp_parser_template_declaration_after_export
../../source/gcc/cp/parser.c:26614
0x62b369 cp_parser_declaration
../../source/gcc/cp/parser.c:12462
...
[Bug c++/80746] [concepts] ICE evaluating constraints for concepts with dependent template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80746 Tom Honermann changed: What|Removed |Added Blocks||67491 --- Comment #1 from Tom Honermann --- This seems likely to be related to: - Bug 67147 - [concepts] ICE on checking concept with default template arguments Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 [Bug 67491] [meta-bug] concepts issues
[Bug c++/67147] [concepts] ICE on checking concept with default template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67147 --- Comment #2 from Tom Honermann --- The following bug looks likely to be related: - Bug 80746 - [concepts] ICE evaluating constraints for concepts with dependent template parameters
