This is the mail system at host fx302.security-mail.net.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<marc.poulh...@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550
5.1.1 <marc.poulh...@kalray.eu>: Recipient address rejected: User unknown
in virtual mailbox table (in reply to RCPT TO command)
Reporting-MTA: dns; fx302.security-mail.net
X-Postfix-Queue-ID: C7D3E3D3B0BF
X-Postfix-Sender: rfc822; gcc-patches@gcc.gnu.org
Arrival-Date: Tue, 10 Aug 2021 15:22:53 +0200 (CEST)
Final-Recipient: rfc822; marc.poulhies@kalray.eu
Original-Recipient: rfc822;marc.poulhies@kalray.eu
Action: failed
Status: 5.1.1
Remote-MTA: dns; zimbra2.kalray.eu
Diagnostic-Code: smtp; 550 5.1.1 <marc.poulhies@kalray.eu>: Recipient address
rejected: User unknown in virtual mailbox table
--- Begin Message ---
On 8/10/21 3:45 AM, Richard Biener wrote:
> On Mon, Aug 9, 2021 at 10:31 PM Andrew MacLeod via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
>> The user has overridden the function name "toupper" . Its marked as a
>> builtin function, presumably because it matches the name. In range
>> folding, we were assuming the LHS and the parameter were compatible
>> types... but they are not in this case..
>>
>> I don't know if we should be marking such a thing as a builtin function,
>> but regardless.. we shouldn't be trapping. If the type of the argument
>> is not compatible with the LHS, then we'll simply assume nothing about
>> the function.
>>
>> Bootstraps with no regression on x86_64-pc-linux-gnu. pushed.
> I wonder why the gimple_call_combined_fn verification
> using gimple_builtin_call_types_compatible_p isn't enough here?
> Yes, it's matching is a bit lazy, but only with respect to promotion
> of arguments to 'int'.
>
> Richard.
>
I set a breakpoint on the return type field for the builtin... A quick
check shows the return type of the builtin is being changed to "unsigned
int" here:
#0 merge_decls (newdecl=0x7fffe9f67100, olddecl=0x7fffe9ed2100,
newtype=0x7fffe9e3ae70, oldtype=0x7fffe9e3ae70) at
/gcc/master/gcc/gcc/c/c-decl.c:2598
#1 0x0000000000a0628d in duplicate_decls (newdecl=0x7fffe9f67100,
olddecl=0x7fffe9ed2100) at /gcc/master/gcc/gcc/c/c-decl.c:2963
#2 0x0000000000a07464 in pushdecl (x=0x7fffe9f67100) at
/gcc/master/gcc/gcc/c/c-decl.c:3256
#3 0x0000000000a1d113 in start_function (declspecs=0x37728b0,
declarator=0x3772ae0, attributes=0x0) at /gcc/master/gcc/gcc/c/c-decl.c:9644
#4 0x0000000000a8667c in c_parser_declaration_or_fndef
(parser=0x7ffff7ff7ab0, fndef_ok=true, static_assert_ok=true,
empty_ok=true, nested=false, start_attr_ok=true,
objc_foreach_object_declaration=0x0,
omp_declare_simd_clauses=0x0, have_attrs=false, attrs=0x0,
oacc_routine_data=0x0, fallthru_attr_p=0x0) at
/gcc/master/gcc/gcc/c/c-parser.c:2444
It would appear that merge_decls is merging the olddecl (the bultin)
with newdecl and results in changing the LHS to unsigned int, so now it
thinks the builtin matches. eeeks.
I don't know what the correct thing to do is, but a quick hack to check
if old_decl is a builtin and return false from duplicate_decl also seems
to resolve the problem:
diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index 221a67fe57b..27ab6ac9f1a 100644
--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -2960,6 +2960,9 @@ duplicate_decls (tree newdecl, tree olddecl)
return false;
}
+ if (DECL_BUILT_IN_CLASS (olddecl) != NOT_BUILT_IN)
+ return false;
+
merge_decls (newdecl, olddecl, newtype, oldtype);
/* The NEWDECL will no longer be needed.
To declare a filtering error, please use the following link :
https://www.security-mail.net/reporter.php?mid=14e68.61127dac.234a0.0&r=marc.poulhies%40kalray.eu&s=gcc-patches-bounces%2Bmarc.poulhies%3Dkalray.eu%40gcc.gnu.org&o=Re%3A+%5BCOMMITTED%5D+PR+tree-optimization%2F101741+-+Ensure+toupper+and+tolower+follow+the+expected+pattern.&verdict=C&c=3fea457da484485891727e6a67eb7e2bee797a0c
--- End Message ---
