[Bug tree-optimization/87776] New: [9 Regression] Compile time hog during RPO VN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87776
Bug ID: 87776
Summary: [9 Regression] Compile time hog during RPO VN
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: compile-time-hog
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-9.0.0-alpha20181021 snapshot (r265361) takes indefinite time to compile the
following snippet w/ -O2 (-O3, -Ofast, -Os) --param rpo-vn-max-loop-depth=2:
int wp;
void
ff (void)
{
int *s3 =
for (wp = 0; wp < 1; ++wp)
{
if (wp != 0)
{
o8:
;
}
else
{
b7:
while (wp < 1)
{
}
}
for (*s3 = 0; *s3 < 1; ++*s3)
{
for (wp = 0; wp < 1; ++wp)
for (wp = 0; wp < 1; ++wp)
{
}
for (wp = 0; wp < 1; ++wp)
goto o8;
for (wp = 0; wp < 1; ++wp)
goto b7;
}
}
}
% timeout 10 gcc-9.0.0-alpha20181021 -O2 --param rpo-vn-max-loop-depth=2 -c
uppnycas.c
zsh: exit 124 timeout 10 gcc-9.0.0-alpha20181021 -O2 --param
rpo-vn-max-loop-depth=2 -c
Or is it something to expect w/ such a small argument for
rpo-vn-max-loop-depth?
[Bug objc/77428] incorrect 'set but not used' warning with @throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77428 --- Comment #5 from Eric Gallager --- (In reply to Tom de Vries from comment #4) > (In reply to Eric Gallager from comment #3) > > (In reply to Tom de Vries from comment #1) > > > Created attachment 39528 [details] > > > tentative patch > > > > Have you sent this patch to the gcc-patches mailing list yet? > > No. Could you please?
[Bug c/71176] trunk/fixincludes/fixincl.c:162: bad % specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71176 --- Comment #4 from Eric Gallager --- (In reply to David Binderman from comment #2) > (In reply to Manuel López-Ibáñez from comment #1) > > I wonder why GCC -Wformat does not catch this, since "static const char" > > literals contents should be visible as formatting strings. In this case, it > > doesn't even make sense to use a separate variable. > > There is a much simpler explanation for this. > > The compiler only sees code that gets through the preprocessor. > > The code in question has > > #ifdef DO_STATS > > around it. > > Still worth fixing, in my view. 2e9 bytes isn't a lot of source code these > days. Where is DO_STATS supposed to be defined?
[Bug target/85035] nios2: adding -fdelete-null-pointer-checks with -O2 enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85035 --- Comment #4 from sandra at gcc dot gnu.org --- Created attachment 44912 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44912=edit assembly language output
[Bug target/85035] nios2: adding -fdelete-null-pointer-checks with -O2 enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85035
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
--- Comment #3 from sandra at gcc dot gnu.org ---
I've looked at this on mainline trunk and I'm not convinced there's a bug here,
or at least not a nios2 backend bug.
The -fdelete-null-pointer-checks option is badly named. What it really does is
allow attempts to dereference a null pointer to be combined and/or replaced
with some other code sequence that also causes a trap. So in the isolate-paths
tree pass, we're getting
if (t_4(D) != 0B)
goto ; [100.00%]
else
goto ; [0.00%]
[count: 0]:
# iftmp.0_8 = PHI <0B(2)>
_9 ={v} iftmp.0_8->m_LL;
__builtin_trap ();
The long long read is tagged as volatile to prevent it from getting optimized
away from later passes, and -mno-cache-volatile says to use the io instructions
for volatile memory reads and writes.
[Bug middle-end/84823] [6 Regression] x86 LRA hang on valid code (no ICE) with -fno-omit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84823 A. Wilcox (awilfox) changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #7 from A. Wilcox (awilfox) --- I have no idea. We can't move to GCC 7.x due to regressions on other platforms, and 8.2.0 chewed more memory than our builders have available. (I should not be seeing oom_killer on a system with 72 GB RAM and -j32, but there it was anyway.) I suppose this can be closed as WONTFIX, if the 6 branch will not be seeing any further updates. I can reopen it if we manage to find a newer GCC release that meets our requirements and this errant behaviour still occurs.
[Bug c++/77796] tautological compare warning emitted for inherited static method comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77796 Eric Gallager changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org, ||dodji at gcc dot gnu.org --- Comment #2 from Eric Gallager --- (In reply to Eric Gallager from comment #1) > Confirmed. Also, it seems weird that the warning underlines all of > B::destroy, but only the "A" in A::destroy: > > $ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 77796.cc > 77796.cc:11:12: warning: self-comparison always evaluates to true > [-Wtautological-compare] > B::destroy == A::destroy ? 0 : 1 > ~~~^~~~ > $ Diagnostics maintainers, do you know what's up with that?
[Bug target/87771] My first 3d printer, and I messed up trying to update the .ini file. So, I'm trying to put the original software back in it, and I get this internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87771
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
Summary|My first 3d printer, and I |My first 3d printer, and I
|messed up trying to update |messed up trying to update
|the .ini file. So, I'm |the .ini file. So, I'm
|trying to put the original |trying to put the original
|software back in it, and I |software back in it, and I
|get this error |get this internal compiler
||error
--- Comment #2 from Eric Gallager ---
(In reply to Donna Ory from comment #0)
> Created attachment 44910 [details]
The part of that output that is actually from gcc is this part:
C:\Users\dory\Documents\Arduino\libraries\U8glib\utility\u8g_rot.c:48:27:
warning: initialization from incompatible pointer type
[-Wincompatible-pointer-types]
u8g_dev_t u8g_dev_rot = { u8g_dev_rot_dummy_fn, NULL, NULL };
^
C:\Users\dory\Documents\Arduino\libraries\U8glib\utility\u8g_rot.c:48:27: note:
(near initialization for 'u8g_dev_rot.dev_fn')
sketch\stepper.cpp: In function 'get_axis_position_mm':
sketch\stepper.cpp:1195:1: internal compiler error: Segmentation fault
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
lto-wrapper.exe: fatal error: C:\Program
Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\tools\avr/bin/avr-gcc
returned 1 exit status
compilation terminated.
c:/program
files/windowsapps/arduinollc.arduinoide_1.8.15.0_x86__mdqgnx93n4wtt/hardware/tools/avr/bin/../lib/gcc/avr/5.4.0/../../../../avr/bin/ld.exe:
error: lto-wrapper failed
collect2.exe: error: ld returned 1 exit status
exit status 1
> Note++ Marlin error
>
> I got the Arduino software off the Windows store, and followed the
> directions given by Thomas Sanladerer on his video on how to upgrade the
> Marlin software.
Could you provide a link to this video please?
> I downloaded the u8glib_arduino_v1.17 zip file,
From where?
> and had the software include it in the libraries.
>
> I have re compiled 4 times, even after opening the "Manage Libraries" so
> they can update...and I still get the same errors.
>
> I don't know how to save in a .i File, but I did copy and paste it into a
> Note++.
>
> I hope you can help me, and I really appreciate what you do!
>
> Sincerely,
> Donna Ory
[Bug c/87775] New: error due __builtin_fprintf having the wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87775
Bug ID: 87775
Summary: error due __builtin_fprintf having the wrong type
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
See also pr87774. GCC fails to compile the program below because it declares
__builtin_fprintf as taking void* rather than FILE* as the first argument (it's
a hack to get around FILE not necessarily being a known type when the built-in
is declared).
$ cat t.c && gcc -O2 -S -Wall -Wextra t.c
#include
int f (const char*, ...);
int ff (FILE*, const char*, ...);
int sf (char*, const char*, ...);
void g (int i, FILE *fp, char *d)
{
(i ? printf : f)("abc");
(i ? fprintf : ff)(fp, "abc");
(i ? sprintf : sf)(d, "abc");
}
void h (int i, FILE *fp, char *d)
{
(i ? __builtin_printf : f)("abc");
(i ? __builtin_fprintf : ff)(fp, "abc");
(i ? __builtin_sprintf : sf)(d, "abc");
}
__typeof__ (fprintf) *pf = __builtin_fprintf;
t.c: In function ‘h’:
t.c:17:26: warning: pointer type mismatch in conditional expression
17 | (i ? __builtin_fprintf : ff)(fp, "abc");
| ^
t.c:17:26: error: called object is not a function or function pointer
17 | (i ? __builtin_fprintf : ff)(fp, "abc");
| ~~~^
t.c: At top level:
t.c:21:28: warning: initialization of ‘int (*)(FILE * restrict, const char *
restrict, ...)’ {aka ‘int (*)(struct _IO_FILE * restrict, const char *
restrict, ...)’} from incompatible pointer type ‘int (*)(void *, const char *,
...)’ [-Wincompatible-pointer-types]
21 | __typeof__ (fprintf) *pf = __builtin_fprintf;
|^
[Bug c++/87774] ICE on ternary expression with __builtin_fprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87774 Martin Sebor changed: What|Removed |Added Keywords||ice-on-valid-code Known to fail||4.3.5, 4.4.7, 4.8.5, 4.9.4, ||5.4.0, 6.4.0, 7.3.0, 8.2.0, ||9.0 --- Comment #1 from Martin Sebor --- It doesn't look like this ever worked correctly. GCC thinks __builtin_fprintf takes a void*.
[Bug c++/87774] New: ICE on ternary expression with __builtin_fprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87774
Bug ID: 87774
Summary: ICE on ternary expression with __builtin_fprintf
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC fails with an ICE on the program below.
#include
extern "C" int ff (FILE*, const char*, ...);
void f (FILE *fp)
{
(fp ? __builtin_fprintf : ff)(fp, "abc");
}
t.C: In function ‘void f(FILE*)’:
t.C:7:29: internal compiler error: canonical types differ for identical types
‘int(FILE*, const char*, ...)’ {aka ‘int(_IO_FILE*, const char*, ...)’} and
‘int(FILE*, const char*, ...)’ {aka ‘int(_IO_FILE*, const char*, ...)’}
7 | (fp ? __builtin_fprintf : ff)(fp, "abc");
| ^~
0xb2ff79 comptypes(tree_node*, tree_node*, int)
/ssd/src/gcc/git-svn/gcc/cp/typeck.c:1480
0x82f723 build_conditional_expr_1
/ssd/src/gcc/git-svn/gcc/cp/call.c:5112
0x830c73 build_conditional_expr(unsigned int, tree_node*, tree_node*,
tree_node*, int)
/ssd/src/gcc/git-svn/gcc/cp/call.c:5460
0xb41d68 build_x_conditional_expr(unsigned int, tree_node*, tree_node*,
tree_node*, int)
/ssd/src/gcc/git-svn/gcc/cp/typeck.c:6668
0x9e858e cp_parser_question_colon_clause
/ssd/src/gcc/git-svn/gcc/cp/parser.c:9473
0x9e869c cp_parser_assignment_expression
/ssd/src/gcc/git-svn/gcc/cp/parser.c:9509
0x9e89dc cp_parser_expression
/ssd/src/gcc/git-svn/gcc/cp/parser.c:9672
0x9ded44 cp_parser_primary_expression
/ssd/src/gcc/git-svn/gcc/cp/parser.c:5255
0x9e320c cp_parser_postfix_expression
/ssd/src/gcc/git-svn/gcc/cp/parser.c:7060
0x9e6695 cp_parser_unary_expression
/ssd/src/gcc/git-svn/gcc/cp/parser.c:8339
0x9e7773 cp_parser_cast_expression
/ssd/src/gcc/git-svn/gcc/cp/parser.c:9107
0x9e7857 cp_parser_binary_expression
/ssd/src/gcc/git-svn/gcc/cp/parser.c:9208
0x9e8651 cp_parser_assignment_expression
/ssd/src/gcc/git-svn/gcc/cp/parser.c:9503
0x9e89dc cp_parser_expression
/ssd/src/gcc/git-svn/gcc/cp/parser.c:9672
0x9ebd29 cp_parser_expression_statement
/ssd/src/gcc/git-svn/gcc/cp/parser.c:11160
0x9eb620 cp_parser_statement
/ssd/src/gcc/git-svn/gcc/cp/parser.c:10964
0x9ec28b cp_parser_statement_seq_opt
/ssd/src/gcc/git-svn/gcc/cp/parser.c:11303
0x9ec181 cp_parser_compound_statement
/ssd/src/gcc/git-svn/gcc/cp/parser.c:11257
0xa004d9 cp_parser_function_body
/ssd/src/gcc/git-svn/gcc/cp/parser.c:21926
0xa0069d cp_parser_ctor_initializer_opt_and_function_body
/ssd/src/gcc/git-svn/gcc/cp/parser.c:21961
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/87773] New: %s directive argument is null missing inlining context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87773
Bug ID: 87773
Summary: %s directive argument is null missing inlining context
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The warning below is missing inlining context. Worse, because it points to the
format string rather than the call, in complex code it could be tricky to
figure out where it's coming from.
Finally, it should probably be controlled by -Wnonnull like other such
warnings.
$ cat t.c && gcc -O2 -S -Wall t.c
void f (char *d, const char *f, const char *p)
{
__builtin_sprintf (d, f, p);
}
void g (char *d)
{
const char *f = "%s";
__builtin_sprintf (d, f, 0);
}
t.c: In function ‘g’:
t.c:8:20: warning: ‘%s’ directive argument is null [-Wformat-overflow=]
8 | const char *f = "%s";
|^~
[Bug target/80024] nios2: unclear wording "numeric digits" in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80024 sandra at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||sandra at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from sandra at gcc dot gnu.org --- Fixed on mainline now.
[Bug target/80024] nios2: unclear wording "numeric digits" in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80024 --- Comment #1 from sandra at gcc dot gnu.org --- Author: sandra Date: Sat Oct 27 21:34:43 2018 New Revision: 265561 URL: https://gcc.gnu.org/viewcvs?rev=265561=gcc=rev Log: 2018-10-27 Sandra Loosemore PR target/80024 gcc/ * config/nios2/nios2.c (nios2_valid_target_attribute_rec): Fix error message. Modified: trunk/gcc/ChangeLog trunk/gcc/config/nios2/nios2.c
[Bug bootstrap/87741] Don't build readline/libreadline.a in GDB, when --with-system-readline is supplied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87741 --- Comment #6 from Дилян Палаузов --- I have misspelled the domain — gnu.gcc.org
[Bug fortran/70914] ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1655
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70914 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED CC||tkoenig at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Thomas Koenig --- I don't think z6.f90 and z7.f90 are valid - the pointer points nowhere sensible, and the assignment can store to anywhere or to NULL. I'd say this is fixed.
[Bug c++/87770] ICE in type_dependent_expression_p, at cp/pt.c:25230
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87770
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #1 from ensadc at mailnesia dot com ---
Reduced:
template struct d {
template d(e);
};
template <> template d::d(e);
template <> template d::d(e) {
long g;
(void)g;
}
template d::d(char);
[Bug ada/87771] My first 3d printer, and I messed up trying to update the .ini file. So, I'm trying to put the original software back in it, and I get this error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87771 --- Comment #1 from Donna Ory --- I'm not a programmer, or anything like that, so I wouldn't know the first thing about adding code or changing it. That said, I just want my Tevo Flash to work as it should before I made the mistake. If I need to download the latest version of the U8glib file to fix the first part, then let me know that. But the other part, I don't have a clue why it would come up.
[Bug c++/87772] New: Crash with variadic template, constexpr constructor for templated non-literal type, using declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87772
Bug ID: 87772
Summary: Crash with variadic template, constexpr constructor
for templated non-literal type, using declaration
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: stypox at pm dot me
Target Milestone: ---
Created attachment 44911
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44911=edit
Preprocessed code from the main.cpp file in the description
* Version:
$g++ --version
g++ (Debian 8.2.0-7) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
* To compile I used (but -save-temps doesn't change anything):
g++ -Wall -g -std=c++17 -o main.o -c main.cpp -save-temps
* Running that command generates the attached preprocessed code and gives this
error:
$g++ -Wall -g -std=c++17 -o main.o -c main.cpp -save-temps
main.cpp: In instantiation of ‘struct
Parser, 1>, 1> >’:
main.cpp:24:53: required from here
main.cpp:16:8: internal compiler error: in is_base_type, at dwarf2out.c:12911
struct Parser {
^~
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
* This is the main.cpp file, in case it is needed. It contains much nonsense
because I removed all the things that didn't change the result of the
compilation. When I write "/* or whatever */" I mean that the value/type there
is just a placeholder and could be anything.
#include
#include
template
struct SentenceBase {
std::string m_code;
constexpr SentenceBase() {}
};
template struct true_all {};
template <>struct true_all<>
: std::true_type {};
template struct true_all :
std::false_type {};
template struct true_all :
true_all::type {};
template
struct Parser {
using rightTypesGuard =
std::enable_if_t...>::value>;
};
template
auto make_parser(Types... sentences) -> Parser...> {}
int main() {
make_parser(std::array, 1 /* or
whatever */>{{}});
}
[Bug rtl-optimization/87701] [9 Regression] ICE in elimination_costs_in_insn, at reload1.c:3640 since r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87701
--- Comment #7 from Segher Boessenkool ---
I have a patch.
rtl.texi has this to say about subregs of hard regs:
===
@item hard registers
It is seldom necessary to wrap hard registers in @code{subreg}s; such
registers would normally reduce to a single @code{reg} rtx. This use of
@code{subreg}s is discouraged and may not be supported in the future.
===
So why is the i386 backend doing this? It seems wrong.
[Bug rtl-optimization/87701] [9 Regression] ICE in elimination_costs_in_insn, at reload1.c:3640 since r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87701 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #6 from Segher Boessenkool --- We start off with (insn 36 35 9 2 (set (reg:V4SI 104) (subreg:V4SI (reg:TI 1 dx [ b ]) 0)) "87701.cc":13:31 -1 (expr_list:REG_DEAD (reg:DI 2 cx) (expr_list:REG_DEAD (reg:DI 1 dx) (nil and replace that with (insn 41 35 42 2 (set (reg:V4SI 107) (reg:TI 1 dx [ b ])) "87701.cc":13:31 -1 (expr_list:REG_DEAD (reg:TI 1 dx [ b ]) (nil))) 42: r104:V4SI=r107:V4SI REG_DEAD r107:V4SI (no long form dump for that last one, sorry). Note the subreg has gone missing. So which is correct here: with or without subreg?
[Bug rtl-optimization/87701] [9 Regression] ICE in elimination_costs_in_insn, at reload1.c:3640 since r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87701 --- Comment #5 from Segher Boessenkool --- I see the problem. Mine.
[Bug ada/87771] New: My first 3d printer, and I messed up trying to update the .ini file. So, I'm trying to put the original software back in it, and I get this error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87771 Bug ID: 87771 Summary: My first 3d printer, and I messed up trying to update the .ini file. So, I'm trying to put the original software back in it, and I get this error Product: gcc Version: lto Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: dory at satx dot rr.com Target Milestone: --- Created attachment 44910 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44910=edit Note++ Marlin error I got the Arduino software off the Windows store, and followed the directions given by Thomas Sanladerer on his video on how to upgrade the Marlin software. I downloaded the u8glib_arduino_v1.17 zip file, and had the software include it in the libraries. I have re compiled 4 times, even after opening the "Manage Libraries" so they can update...and I still get the same errors. I don't know how to save in a .i File, but I did copy and paste it into a Note++. I hope you can help me, and I really appreciate what you do! Sincerely, Donna Ory
[Bug rtl-optimization/87701] [9 Regression] ICE in elimination_costs_in_insn, at reload1.c:3640 since r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87701 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|2018-10-23 00:00:00 |2018-10-27 Ever confirmed|0 |1 --- Comment #4 from Segher Boessenkool --- Confirmed.
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #65 from Segher Boessenkool --- Iain: This is fine for trunk and all open branches you want it on. Thanks!
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 Iain Sandoe changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #64 from Iain Sandoe --- so all languages, m32/m64, --enable-checking=all,rtl,tree trunk bootstrap completed without error (with the patch above + one to enable Ada to work on Darwin9). "Only" 16h of CPU time on a 2G5 cpu ;) Smoke-tested only; full suite will take "some time". So - at least w.r.t the boostrap bug, I'm declaring victory for trunk/8.x and will do a second revision for 7.x (unless it can be proven not to be needed there). @segher - still OK for application or would you like me to post the revised patch? (I want to modify the comment slightly to note that the FRAME_GROWS_DOWNWARD case is the only one relevant here, which is why the other arm of the original ternary got removed).
[Bug c++/87770] New: ICE in type_dependent_expression_p, at cp/pt.c:25230
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87770
Bug ID: 87770
Summary: ICE in type_dependent_expression_p, at cp/pt.c:25230
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: konraddabrowski at yahoo dot co.uk
Target Milestone: ---
This affects g++ 8 and trunk (tested on r265559), but not 7.3.0. It first
occurs in r249323.
The corresponding patch (r249333) in the g++7 branch doesn't seem to cause
problems there.
This may be a duplicate of bug 87714.
$ g++ -v -c equals3.cc
Using built-in specs.
COLLECT_GCC=/home/sage/ppl/bin4/bin/g++
Target: x86_64-pc-linux-gnu
Configured with: /home/sage/gcc/configure --prefix=/home/sage/ppl/bin4
--enable-languages=c,c++
Thread model: posix
gcc version 9.0.0 20181027 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/home/sage/ppl/bin4/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/cc1plus -quiet -v
-imultiarch x86_64-linux-gnu -D_GNU_SOURCE equals3.cc -quiet -dumpbase
equals3.c
c -mtune=generic -march=x86-64 -auxbase equals3 -version -o /tmp/cc7QKAEq.s
GNU C++14 (GCC) version 9.0.0 20181027 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 9.0.0 20181027 (experimental), GMP version
6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.20-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/home/sage/ppl/bin4/lib/gcc/x86_64-pc-linux-gnu/9.0.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/home/sage/ppl/bin4/lib/gcc/x86_64-pc-linux-gnu/9.0.0/../../../../include/c++/9.0.0
/home/sage/ppl/bin4/lib/gcc/x86_64-pc-linux-gnu/9.0.0/../../../../include/c++/9.0.0/x86_64-pc-linux-gnu
/home/sage/ppl/bin4/lib/gcc/x86_64-pc-linux-gnu/9.0.0/../../../../include/c++/9.0.0/backward
/home/sage/ppl/bin4/lib/gcc/x86_64-pc-linux-gnu/9.0.0/include
/usr/local/include
/home/sage/ppl/bin4/include
/home/sage/ppl/bin4/lib/gcc/x86_64-pc-linux-gnu/9.0.0/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
GNU C++14 (GCC) version 9.0.0 20181027 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 9.0.0 20181027 (experimental), GMP version
6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.20-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 7f3b9e82dac49b25cf1b2683fd4c3f1b
equals3.cc: In instantiation of ‘d< >::d(const d&,
a) [with e = c; = int]’:
equals3.cc:21:8: required from here
equals3.cc:15:18: internal compiler error: in type_dependent_expression_p, at
cp/pt.c:25230
15 | for (B g, h; g != h;)
|~~^~~~
0x6446f6 type_dependent_expression_p(tree_node*)
/home/sage/gcc/gcc/cp/pt.c:25230
0x6446f6 type_dependent_expression_p(tree_node*)
/home/sage/gcc/gcc/cp/pt.c:25069
0x97c0fd uses_template_parms(tree_node*)
/home/sage/gcc/gcc/cp/pt.c:10036
0x98453f tsubst_copy
/home/sage/gcc/gcc/cp/pt.c:15438
0x99ea41 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/sage/gcc/gcc/cp/pt.c:18907
0x99f1ae tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/sage/gcc/gcc/cp/pt.c:18694
0x99f418 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/sage/gcc/gcc/cp/pt.c:18309
0x985007 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/sage/gcc/gcc/cp/pt.c:17455
0x985807 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/sage/gcc/gcc/cp/pt.c:16797
0x98506b tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/sage/gcc/gcc/cp/pt.c:16939
0x986ff5 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/sage/gcc/gcc/cp/pt.c:16636
0x98506b tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/sage/gcc/gcc/cp/pt.c:16939
0x9b2f97 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/sage/gcc/gcc/cp/pt.c:16621
0x9b2f97 instantiate_decl(tree_node*, bool, bool)
/home/sage/gcc/gcc/cp/pt.c:24107
0x9b6d0b instantiate_pending_templates(int)
/home/sage/gcc/gcc/cp/pt.c:24223
0x8db400 c_parse_final_cleanups()
/home/sage/gcc/gcc/cp/decl2.c:4709
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Minimal working example: equals3.cc:
enum a { b };
class c;
class B {
public:
bool operator!=(B);
};
template class d {
public
[Bug fortran/85896] ICE in gfc_convert_constant(): Unexpected type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85896
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment #3 from Thomas Koenig ---
(In reply to G. Steinmetz from comment #0)
> Affects versions down to at least 4.8 :
>
>
> $ cat z1.f90
> program p
>integer :: min
>print *, min('a','b')
> end
>
>
> $ cat z2.f90
> program p
>real :: max
>print *, max('a','b')
> end
>
What is the expected output? Does this declare a new variable "min"
or "max", or should the result simply be 'a' (or 'b')?
I have looked at the standard, but didn't find anything relevent.
[Bug fortran/86907] [9 Regression] bogus warning "No location in expression near"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86907 Thomas Koenig changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #11 from Thomas Koenig --- OK, sowe can close this.
[Bug fortran/86907] [9 Regression] bogus warning "No location in expression near"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86907 --- Comment #10 from Jürgen Reuter --- (In reply to Thomas Koenig from comment #9) > This makes the error message a litte bit clearer, to make sure > it is understood that this is the compiler's fault, not the user's. > > However, I cannot reproduce the original problem. Dear Thomas, I didn't check your changes (but they only modify the warning message as far as I understand). I already confirmed to Dominique that for the code I submitted (and also our full code) the warning does not appear any more.
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 Douglas Mencken changed: What|Removed |Added Attachment #44902|0 |1 is obsolete|| --- Comment #63 from Douglas Mencken --- Created attachment 44909 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44909=edit 8.2iain-pr78468.s Assembly of pr78468.s by GCC 8.2 with Iain’s patch --- 8.2vanilla-pr78468.s +++ 8.2iain-pr78468.s @@ -85,7 +85,7 @@ li r7,0 li r5,0 li r4,0 - addi r2,r1,72 + addi r2,r1,80 stw r6,60(r1) stw r2,56(r1) li r6,0 @@ -118,7 +118,7 @@ li r8,0 li r5,0 li r4,0 - addi r2,r1,72 + addi r2,r1,80 stw r6,64(r1) stw r7,60(r1) li r3,0 @@ -152,7 +152,7 @@ li r7,0 li r5,0 li r4,0 - addi r2,r1,72 + addi r2,r1,80 stw r6,60(r1) stw r2,56(r1) li r6,0 @@ -185,7 +185,7 @@ li r8,0 li r5,0 li r4,0 - addi r2,r1,72 + addi r2,r1,80 stw r6,64(r1) stw r7,60(r1) li r3,0 @@ -286,7 +286,7 @@ li r7,0 li r5,0 li r4,0 - addi r2,r1,103 + addi r2,r1,111 stw r6,60(r1) rlwinm r2,r2,0,0,26 li r6,0 @@ -320,7 +320,7 @@ li r8,0 li r5,0 li r4,0 - addi r2,r1,103 + addi r2,r1,111 stw r6,64(r1) rlwinm r2,r2,0,0,26 stw r7,60(r1)
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #62 from Douglas Mencken --- (In reply to Iain Sandoe from comment #61) > Created attachment 44908 [details] > Proposed 8.x patch > > here is the revised patch for the post wi::int_traits world. Works For Me(tm) > > Please confirm for your use-case. It works for me™ too
[Bug fortran/86907] [9 Regression] bogus warning "No location in expression near"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86907 Thomas Koenig changed: What|Removed |Added Status|NEW |WAITING --- Comment #9 from Thomas Koenig --- This makes the error message a litte bit clearer, to make sure it is understood that this is the compiler's fault, not the user's. However, I cannot reproduce the original problem.
[Bug fortran/86907] [9 Regression] bogus warning "No location in expression near"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86907 --- Comment #8 from Thomas Koenig --- Author: tkoenig Date: Sat Oct 27 10:26:23 2018 New Revision: 265559 URL: https://gcc.gnu.org/viewcvs?rev=265559=gcc=rev Log: 2018-10-27 Thomas Koenig PR fortran/86907 * frontend-passes.c (check_locus_code): Add information that warning about missing location information points to an inconsisten internal state. (check_locus_expr): Likewise. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/frontend-passes.c
[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352 --- Comment #4 from Jeremy Sanders --- Janne: This problem is also present on version 7, whereas the other bug is new in 8. There may be a relation, however.
[Bug libstdc++/87106] Group move and destruction of the source, where possible, for speed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106 --- Comment #11 from Marc Glisse --- (In reply to Arthur O'Dwyer from comment #10) > Here's the commit where I trivially-relocatable-ized `std::deque`. 34 lines > added, 18 more lines changed. There's some duplication, but it's not > literally "duplicating the whole class." Indeed. It requires defaulting some methods in the outer class. And it requires some artificial base classes, something I've been fighting against with [[unique_address]]. But it looks doable... > > I was looking into using relocation in std::swap. ... Maybe types that are > > trivially relocatable but not trivially movable and destructible? Or just > > non-trivial? > > My commit for `std::swap` is here: > https://github.com/Quuxplusone/libcxx/commit/ > 4d89aa95a7da86d1671d3e4441967782399fc3f9#diff- > d436eb0fd9de10b54a828ce6435f7e81 > It's extremely naive. I just say, if the type is_trivially_relocatable, then > we use memcpy --- EXCEPT, if the type is_empty, then we should NOT use > memcpy, because that is highly likely to break real code. > https://quuxplusone.github.io/blog/2018/07/13/trivially-copyable-corner- > cases/ Those are real pre-existing problems. As long as we deal with vector, we know that T is the real type so we are safe. But indeed for one-element functions like swap it is more dangerous. I was considering not just cases that are dangerous, but also cases (like int) that are safe but where memcpy might hinder some optimizations using tbaa. > I'm not sure I follow. Are you relying on the premise that move-constructing > an object, and then destructing a moved-from object, is more expensive than > move-assigning into a moved-from object? I would expect move-assigning to be > *no cheaper* than move-constructing, and so constructing and destructing a > new temporary for each element ought to be *no more expensive* (and possibly > cheaper) than reusing the same one. For a type that always has some memory allocated, say std::list in visual studio, constructing+destructing means allocating and deallocating a sentinel, which can be skipped when assigning.
[Bug rtl-optimization/85410] ICE in create_block_for_bookkeeping, at sel-sched.c:4563
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85410
--- Comment #3 from Arseny Solokha ---
Testcase from #c2 doesn't fail for me anymore w/ the current trunk snapshot (as
of r265361), but the following one does:
int py, up;
void
ro (int *tr, int et)
{
while (et < 1)
{
int s7 = !!*tr ? 0 : py;
if (s7 != 0)
{
}
else
{
up /= 2;
if (py * py == 0)
tr =
}
++et;
}
}
% x86_64-unknown-linux-gnu-gcc-9.0.0-alpha20181021 -O1 -fschedule-insns
-fsel-sched-pipelining -fselective-scheduling -fvar-tracking-assignments
-fno-if-conversion -fno-tree-loop-im -w -c ebmjprna.c
during RTL pass: sched1
ebmjprna.c: In function 'ro':
ebmjprna.c:23:1: internal compiler error: in create_block_for_bookkeeping, at
sel-sched.c:4563
23 | }
| ^
0x65a9e8 create_block_for_bookkeeping
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181021/work/gcc-9-20181021/gcc/sel-sched.c:4563
0x65a9e8 find_place_for_bookkeeping
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181021/work/gcc-9-20181021/gcc/sel-sched.c:4700
0x65a9e8 generate_bookkeeping_insn
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181021/work/gcc-9-20181021/gcc/sel-sched.c:4800
0x65a9e8 move_op_at_first_insn
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181021/work/gcc-9-20181021/gcc/sel-sched.c:6077
0xc9016c code_motion_path_driver
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181021/work/gcc-9-20181021/gcc/sel-sched.c:6669
0xc90516 code_motion_process_successors
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181021/work/gcc-9-20181021/gcc/sel-sched.c:6356
0xc90516 code_motion_path_driver
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181021/work/gcc-9-20181021/gcc/sel-sched.c:6622
0xc90516 code_motion_process_successors
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181021/work/gcc-9-20181021/gcc/sel-sched.c:6356
0xc90516 code_motion_path_driver
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181021/work/gcc-9-20181021/gcc/sel-sched.c:6622
0xc93292 move_op
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181021/work/gcc-9-20181021/gcc/sel-sched.c:6714
0xc93292 move_exprs_to_boundary
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181021/work/gcc-9-20181021/gcc/sel-sched.c:5237
0xc93292 schedule_expr_on_boundary
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181021/work/gcc-9-20181021/gcc/sel-sched.c:5450
0xc951cc fill_insns
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181021/work/gcc-9-20181021/gcc/sel-sched.c:5592
0xc951cc schedule_on_fences
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181021/work/gcc-9-20181021/gcc/sel-sched.c:7366
0xc951cc sel_sched_region_2
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181021/work/gcc-9-20181021/gcc/sel-sched.c:7504
0xc96a56 sel_sched_region_1
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181021/work/gcc-9-20181021/gcc/sel-sched.c:7546
0xc9822e sel_sched_region(int)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181021/work/gcc-9-20181021/gcc/sel-sched.c:7647
0xc9822e sel_sched_region(int)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181021/work/gcc-9-20181021/gcc/sel-sched.c:7632
0xc99141 run_selective_scheduling()
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181021/work/gcc-9-20181021/gcc/sel-sched.c:7733
0xc78edd rest_of_handle_sched
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181021/work/gcc-9-20181021/gcc/sched-rgn.c:3718
[Bug rtl-optimization/87701] [9 Regression] ICE in elimination_costs_in_insn, at reload1.c:3640 since r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87701 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #3 from David Binderman --- Code compiles ok at -O2, so -O3 required. Bug seems to first appear somewhere between revision 265367 and 265411.
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 Iain Sandoe changed: What|Removed |Added Attachment #44901|0 |1 is obsolete|| Status|NEW |WAITING Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org --- Comment #61 from Iain Sandoe --- Created attachment 44908 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44908=edit Proposed 8.x patch here is the revised patch for the post wi::int_traits world. Works For Me(tm) Please confirm for your use-case. I expect this variant will be suitable for trunk (testing later) A slightly different version will be needed for 7.x (TBD).
[Bug tree-optimization/87473] [7/8/9 Regression] ICE in create_add_on_incoming_edge, at gimple-ssa-strength-reduction.c:2344
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87473 Arseny Solokha changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Arseny Solokha --- So fixed everywhere.
