[Bug c++/87692] Reuse guard variable for multiple initializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87692 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-23 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug tree-optimization/87700] New: [9 Regression] Compile time hog w/ -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87700
Bug ID: 87700
Summary: [9 Regression] Compile time hog w/ -O1
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 when compiling
the following snippet w/ -O1:
void
wn (int ki)
{
int m8 = 0;
int *d6 = &ki;
if (ki == 0)
{
ud:
for (ki = 0; ki < 1; ++ki)
for (m8 = 0; m8 < 1; ++m8)
goto ud;
d6 = &m8;
y8:
++m8;
xw:
if (ki == 0)
{
}
else
{
for (m8 = 0; m8 < 1; ++m8)
{
gt:
if (*d6 == 0)
goto y8;
}
for (m8 = 0; m8 < 1; ++m8)
{
goto gt;
ym:
;
}
}
d6 = &ki;
goto ym;
}
goto xw;
}
% timeout 10 gcc-9.0.0-alpha20181021 -O1 -c ehynqp9p.c
zsh: exit 124 timeout 10 gcc-9.0.0-alpha20181021 -O1 -c ehynqp9p.c
perf top:
Overhead Sha Symbol
15.94% cc1 [.] operand_equal_p
14.86% cc1 [.] inchash::add_expr
12.49% cc1 [.] add_ssa_edge
8.54% cc1 [.] copy_prop::visit_phi
7.87% cc1 [.] ssa_propagation_engine::simulate_stmt
6.65% cc1 [.] iterative_hash
6.41% cc1 [.] ssa_propagation_engine::ssa_propagate
6.05% cc1 [.] bitmap_set_bit
4.07% cc1 [.] useless_type_conversion_p
3.71% cc1 [.] iterative_hash_host_wide_int
2.68% cc1 [.] may_propagate_copy
2.68% cc1 [.] bitmap_clear_bit
2.51% cc1 [.] tree_operand_check
2.42% cc1 [.] bitmap_first_set_bit
1.91% cc1 [.] tree_strip_nop_conversions
0.89% cc1 [.] element_precision
0.31% cc1 [.] commutative_tree_code
[Bug c++/87667] -Wformat + typed enum class - difference with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87667 Roman Lebedev changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED See Also||https://bugs.llvm.org/show_ ||bug.cgi?id=39369 Resolution|--- |INVALID --- Comment #4 from Roman Lebedev --- clang agrees that the problem seems to be on their side.
[Bug c++/87699] New: Implement CWG 1512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87699
Bug ID: 87699
Summary: Implement CWG 1512
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tiagomacarios at gmail dot com
Target Milestone: ---
As per http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3478.html
the below should not compile.
https://godbolt.org/z/mOpxau
bool foo(int* bar)
{
return bar > 0;
}
[Bug c++/49574] Give a warning for insane overloading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49574 --- Comment #6 from Eric Gallager --- (In reply to Jonathan Wakely from comment #5) > The description of what the warning is supposed to do is still incredibly > vague and unspecified. It's whatever you agreed to here: (In reply to Jonathan Wakely from comment #2) > > I agree a warning when the functions are declared could be useful for > finding the problem earlier
[Bug c/87038] diagnostics: Please add warning for jumping over initializers with switch/case in C mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038 --- Comment #21 from Harald van Dijk --- (In reply to Segher Boessenkool from comment #20) > That is still not what I said, so don't pretend I did please. > > Those are also not false positives: in all these cases, the program does > in fact skip some initialisation. "Pretend"? When you misrepresented my words, I did not accuse you of any type of deception, I assumed it was simply a misunderstanding and responded accordingly. I'd appreciate the same treatment from you. You made an ambiguous comment which I did not recognise as ambiguous at the time. You wrote: > -Wall please, unless there are frequent false positives. [...] "False positive" can be interpreted in two ways. It can be read as a false positive wrt -Wjump-misses-init, meaning a warning where no initialisation is jumped over. It turns out this is what you meant. It can also be read as I did, which is a false positive wrt -Wall, which is documented as: > This enables all the warnings about constructions that some users > consider questionable, and that are easy to avoid (or modify to > prevent the warning), even in conjunction with macros. [...] A false positive here would mean that the warning is either about a construct that users do not consider questionable, or that is not easy to avoid. I was responding based on the assumption that this is what you meant. Initialisation is commonly jumped over in large bodies of C code, which is a good indication that it is not largely considered questionable, and of the cases I'd found, although all can be worked around to suppress the warning, quite a lot of them would get a lot uglier. It did not even scan to me that you might be saying that the only reason you'd not propose -Wjump-misses-init be included in -Wall is if -Wjump-misses-init doesn't do what it's supposed to. > But, it seems -Wjump-misses-init is not what you want; you do not want a > warning for jumping over initialisers, it warns for a lot of harmless code. > What you want is a warning that only warns if the var is (potentially) used > without initialisation? Yes, at least for -Wall. Since -Wjump-misses-init triggers too often for commonly used C patterns, I do not think it is appropriate to include it in -Wall. At the same time, for the originally reported code, it does seem like *some* warning at -Wall would be appropriate. A warning about the use of the potentially-uninitialised variable, as clang does, seems sensible to me.
[Bug lto/87698] [lto] Shared library build with -ffat-lto-objects generates extra global absolute symbol relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87698 --- Comment #1 from Romain Geissler --- Note: this is the source of the following error when linking with ld.lld 7.0: ld.lld: error: corrupt input file: version definition index 0 for symbol _libssh2_ntohu32 is out of bounds >>> defined in >>> /projects/combld/delivery/continuous/components.osp/osp/SSH2/18-0-0-0/lib/x86_64-2.6.32-v4/Debug/libssh2.so Don't know if this particular behavior is a ld.lld bug though, I actually don't expect these symbols to be even defined in the final libssh2.so.
[Bug lto/87698] New: [lto] Shared library build with -ffat-lto-objects generates extra global absolute symbol relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87698 Bug ID: 87698 Summary: [lto] Shared library build with -ffat-lto-objects generates extra global absolute symbol relocations Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: romain.geissler at amadeus dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Hi, Is it expected that a shared library where each .o file has been built with -flto -ffat-lto-objects has more symbol relocation (absolute symbol relocations) than the very same shared library built with -flto -ffat-lto-objects ? With gcc 8.2.1 20181011 I have the following symbols defined in the case of fat lto objects when building libssh2 (https://github.com/libssh2/libssh2): /opt/1A/toolchain/x86_64-2.6.32-v4/bin/readelf -a ~combld/delivery/continuous/components.osp/osp/SSH2/18-0-0-0/lib/x86_64-2.6.32-v4/Debug/libssh2.so|grep ABS 138: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_session_set_bloc 142: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_store_str 143: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_sha1_init 149: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_list_next 152: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_comp_methods 154: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_ntohu64 155: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_init_aes_ctr 159: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_dsa_sha1_verify 163: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_list_first 168: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_base64_encode 170: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_rsa_new_private_ 172: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_pub_priv_keyfile 178: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_channel_locate 179: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_kex_exchange 186: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_transport_read 187: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_channel_extended 188: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_channel_read 191: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_rsa_sha1_verify 194: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_packet_burn 198: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_ntohu32 200: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_userauth_publick 203: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_channel_receive_ 204: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_dsa_new_private_ 205: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_pub_priv_keyfile 206: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_dsa_sha1_sign 209: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_channel_free 215: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_list_init 217: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_channel_write 223: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_htonu32 224: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_channel_close 228: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_send 230: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_channel_forward_ 232: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_dsa_new_private 235: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_sha256_init 236: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_recv 245: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_md5_init 247: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_packet_requirev 250: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_channel_process_ 251: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_packet_require 260: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_list_add 264: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_wait_socket 265: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_packet_ask 267: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_cipher_init 271: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_rsa_sha1_sign 272: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_error_flags 273: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_rsa_new_private 275: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_dsa_new 282: 0 NOTYPE GLOBAL DEFAULT ABS _libssh2_error 285: 0
[Bug c++/87697] New: Casting a base class to derived gives no warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87697 Bug ID: 87697 Summary: Casting a base class to derived gives no warning Product: gcc Version: 7.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jynelson at email dot sc.edu Target Milestone: --- Created attachment 44881 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44881&action=edit The preprocessed source Casting a base class to a derived class gives no warning, even with -Wall -Werror enabled. I've been told on IRC that this sort of cast is undefined behaviour according to spec if neither class is virtual. If that is the case, it would be nice to have a warning. If that isn't the case, there are several more questions that arise, like `why does c1 have access to c2` and `why can the const value c2::x be accessed without be initialized`? $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 7.3.1 20180303 (Red Hat 7.3.1-5) (GCC) $ g++ -Wall -Werror inheritance.cc $ ./a.out constructor 1 c2: 0
[Bug web/87696] gcc-patches mail archive does not show attachments clearly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87696 --- Comment #1 from Andrew Pinski --- Raw format still has that information. I think this is just an artifact of how to display attachments and nothing is lost really.
[Bug web/87696] New: gcc-patches mail archive does not show attachments clearly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87696 Bug ID: 87696 Summary: gcc-patches mail archive does not show attachments clearly Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- See, for example, https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01360.html . The original mail contained one gzipped attachment (due to the size restrictions) and seven test cases. The web entry shows the attachment as separate file (which is OK) and loses all information about where one attachment starts and the other ends, and what they were originally called.
[Bug c++/85552] Adding curly braces to the declaration of a std::unique_ptr to a forward declared class breaks compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85552 --- Comment #4 from Tiago Macarios --- Related clang bug: https://bugs.llvm.org/show_bug.cgi?id=39363
[Bug tree-optimization/87633] [9 Regression] ice in compare_range_wit h_value, at vr-values.c:1702
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87633 --- Comment #10 from Yury Gribov --- Let me know if issue persists, otherwise I'll close in couple of days.
[Bug c++/49574] Give a warning for insane overloading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49574 Jonathan Wakely changed: What|Removed |Added Status|NEW |WAITING --- Comment #5 from Jonathan Wakely --- The description of what the warning is supposed to do is still incredibly vague and unspecified.
[Bug tree-optimization/87633] [9 Regression] ice in compare_range_wit h_value, at vr-values.c:1702
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87633 --- Comment #9 from Yury Gribov --- Author: ygribov Date: Mon Oct 22 20:26:32 2018 New Revision: 265399 URL: https://gcc.gnu.org/viewcvs?rev=265399&root=gcc&view=rev Log: 2018-10-22 Yury Gribov gcc/ PR tree-optimization/87633 * match.pd: Do not generate unordered integer comparisons. gcc/testsuite/ PR tree-optimization/87633 * g++.dg/pr87633.C: New test. Added: trunk/gcc/testsuite/g++.dg/pr87633.C Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/87600] Fix for PRs 86939 and 87479 causes build issues for several targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87600 --- Comment #5 from Segher Boessenkool --- Author: segher Date: Mon Oct 22 20:23:39 2018 New Revision: 265398 URL: https://gcc.gnu.org/viewcvs?rev=265398&root=gcc&view=rev Log: combine: Do not combine moves from hard registers On most targets every function starts with moves from the parameter passing (hard) registers into pseudos. Similarly, after every call there is a move from the return register into a pseudo. These moves usually combine with later instructions (leaving pretty much the same instruction, just with a hard reg instead of a pseudo). This isn't a good idea. Register allocation can get rid of unnecessary moves just fine, and moving the parameter passing registers into many later instructions tends to prevent good register allocation. This patch disallows combining moves from a hard (non-fixed) register. This also avoid the problem mentioned in PR87600 #c3 (combining hard registers into inline assembler is problematic). Because the register move can often be combined with other instructions *itself*, for example for setting some condition code, this patch adds extra copies via new pseudos after every copy-from-hard-reg. On some targets this reduces average code size. On others it increases it a bit, 0.1% or 0.2% or so. (I tested this on all *-linux targets). PR rtl-optimization/87600 * combine.c: Add include of expr.h. (cant_combine_insn_p): Do not combine moves from any hard non-fixed register to a pseudo. (make_more_copies): New function, add a copy to a new pseudo after the moves from hard registers into pseudos. (rest_of_handle_combine): Declare rebuild_jump_labels_after_combine later. Call make_more_copies. Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c
[Bug other/87695] New: Fehler beim Kompilieren für das Board Arduino/Genuino Mega or Mega 2560.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87695 Bug ID: 87695 Summary: Fehler beim Kompilieren für das Board Arduino/Genuino Mega or Mega 2560. Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: mgruehs at gmx dot de Target Milestone: --- what does this message want to tell me? Arduino: 1.8.7 (Windows Store 1.8.15.0) (Windows 10), Board: "Arduino/Genuino Mega or Mega 2560, ATmega2560 (Mega 2560)" C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\arduino-builder -dump-prefs -logger=machine -hardware C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware -tools C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\tools-builder -tools C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\tools\avr -built-in-libraries C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\libraries -libraries C:\Users\SAMAMOFA\Documents\Arduino\libraries -fqbn=arduino:avr:mega:cpu=atmega2560 -ide-version=10807 -build-path C:\Users\SAMAMOFA\AppData\Local\Temp\arduino_build_439479 -warnings=none -build-cache C:\Users\SAMAMOFA\AppData\Local\Temp\arduino_cache_930089 -prefs=build.warn_data_percentage=75 -prefs=runtime.tools.avrdude.path=C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\tools\avr -prefs=runtime.tools.avrdude-6.3.0-arduino14.path=C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\tools\avr -prefs=runtime.tools.avr-gcc.path=C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\tools\avr -prefs=runtime.tools.avr-gcc-5.4.0-atmel3.6.1-arduino2.path=C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\tools\avr -prefs=runtime.tools.arduinoOTA.path=C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\tools\avr -prefs=runtime.tools.arduinoOTA-1.2.1.path=C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\tools\avr -verbose C:\Users\SAMAMOFA\Documents\Arduino\Lokschuppen4Tore_Servo_Taster_LED\Lokschuppen4Tore_Servo_Taster_LED.ino C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\arduino-builder -compile -logger=machine -hardware C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware -tools C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\tools-builder -tools C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\tools\avr -built-in-libraries C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\libraries -libraries C:\Users\SAMAMOFA\Documents\Arduino\libraries -fqbn=arduino:avr:mega:cpu=atmega2560 -ide-version=10807 -build-path C:\Users\SAMAMOFA\AppData\Local\Temp\arduino_build_439479 -warnings=none -build-cache C:\Users\SAMAMOFA\AppData\Local\Temp\arduino_cache_930089 -prefs=build.warn_data_percentage=75 -prefs=runtime.tools.avrdude.path=C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\tools\avr -prefs=runtime.tools.avrdude-6.3.0-arduino14.path=C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\tools\avr -prefs=runtime.tools.avr-gcc.path=C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\tools\avr -prefs=runtime.tools.avr-gcc-5.4.0-atmel3.6.1-arduino2.path=C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\tools\avr -prefs=runtime.tools.arduinoOTA.path=C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\tools\avr -prefs=runtime.tools.arduinoOTA-1.2.1.path=C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\tools\avr -verbose C:\Users\SAMAMOFA\Documents\Arduino\Lokschuppen4Tore_Servo_Taster_LED\Lokschuppen4Tore_Servo_Taster_LED.ino Using board 'mega' from platform in folder: C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\arduino\avr Using core 'arduino' from platform in folder: C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\hardware\arduino\avr Detecting libraries used... "C:\\Program Files\\WindowsApps\\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\\hardware\\tools\\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega2560 -DF_CPU=1600L -DARDUINO=10807 -DARDUINO_AVR_MEGA2560 -DARDUINO_ARCH_AVR "-IC:\\Program Files\\WindowsApps\\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqg
[Bug testsuite/87694] [9 regression] problem in g++.dg/concepts/memfun-err.C starting with r263343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87694 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Done.
[Bug testsuite/87694] [9 regression] problem in g++.dg/concepts/memfun-err.C starting with r263343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87694 --- Comment #2 from Marek Polacek --- Author: mpolacek Date: Mon Oct 22 20:01:56 2018 New Revision: 265397 URL: https://gcc.gnu.org/viewcvs?rev=265397&root=gcc&view=rev Log: PR testsuite/87694 * g++.dg/concepts/memfun-err.C: Make it a compile test. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C
[Bug c++/55254] Warn for implicit conversion from int to char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55254 --- Comment #3 from Eric Gallager --- Should this go under the existing -Wconversion or a new flag? If the latter, I'll make this block the new-warning meta-bug.
[Bug c++/49574] Give a warning for insane overloading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49574 Eric Gallager changed: What|Removed |Added Blocks||87403 --- Comment #4 from Eric Gallager --- This warning would be new if added. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug c/60440] Bogus -Wreturn-type warning after error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60440 --- Comment #11 from Eric Gallager --- (In reply to Martin Liška from comment #10) > Agree with Joseph, but it's a low priority on my list. It's kind of error > recovery and as soon you fix the first warning you should not see the second > one. I prefer fixing things in order of how difficult the fix is, and adding a second return (while pointless, redundant, and unnecessary) is often easier than tracking down where the code's original author declared the undeclared identifiers.
[Bug c/87691] transparent_union attribute does not work with MODE_PARTIAL_INT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87691 --- Comment #5 from Jozef Lawrynowicz --- (In reply to Richard Biener from comment #4) Thanks for the pointers. > What happens if you make the attribute work for a MODE_INT union with a > MODE_PARTIAL_INT first field that has MODE_SIZE of the union mode? > > Is there > a generic way to query SImode for PSImode as defined in > > PARTIAL_INT_MODE (SI, 20, PSI); > > ? Or does one need to compare MODE_SIZE? I believe you just have to compare MODE_SIZE as I did below. > Can there be multiple non-partial integer modes with the same size? Currently for the targets using PARTIAL_INT_MODE there is only a one-to-one mapping from the "full" mode to the partial mode. But where it can get tricky is when examining the BITSIZE of a partial int mode, as depending on the context, the bitsize could be the bitsize of the SI mode or the true bitsize of the PSImode i.e. the precision. I tried this (there may well be a neater way): diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c index 4416b50..74f6a76 100644 --- a/gcc/c-family/c-attribs.c +++ b/gcc/c-family/c-attribs.c @@ -1280,7 +1280,11 @@ handle_transparent_union_attribute (tree *node, tree name, tree first = first_field (type); if (first == NULL_TREE || DECL_ARTIFICIAL (first) - || TYPE_MODE (type) != DECL_MODE (first)) + || (TYPE_MODE (type) != DECL_MODE (first) + && !(GET_MODE_CLASS (TYPE_MODE (type)) == MODE_INT + && GET_MODE_CLASS (DECL_MODE(first)) == MODE_PARTIAL_INT + && known_eq (GET_MODE_BITSIZE (TYPE_MODE (type)), + GET_MODE_BITSIZE (DECL_MODE (first)) goto ignored; } It fixes most of those failing DejaGNU tests, except pr34885.c ends up ICE-ing at "-O3 -g". during RTL pass: final^M /home/jozef/msp430/gcc/gcc/testsuite/gcc.c-torture/compile/pr34885.c: In function 'send':^M /home/jozef/msp430/gcc/gcc/testsuite/gcc.c-torture/compile/pr34885.c:9:1: internal compiler error: Segmentation fault^M 0xb58f4f crash_signal^M ../../gcc/toplev.c:325^M 0x7bf92d gen_subprogram_die^M ../../gcc/dwarf2out.c:23270^M 0x7c1c5b gen_decl_die^M ../../gcc/dwarf2out.c:26197^M 0x7c3f9e dwarf2out_decl^M ../../gcc/dwarf2out.c:26765^M 0x7d707e dwarf2out_function_decl^M ../../gcc/dwarf2out.c:26780^M 0x83e757 rest_of_handle_final^M ../../gcc/final.c:4681^M 0x83e757 execute^M ../../gcc/final.c:4723^M I haven't investigated the above ICE as the below alternative approach fixes the issue and offers codegen benefits. diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c index 58a3aa3..6449f16 100644 --- a/gcc/stor-layout.c +++ b/gcc/stor-layout.c @@ -1844,10 +1844,15 @@ compute_record_mode (tree type) } /* If we only have one real field; use its mode if that mode's size - matches the type's size. This only applies to RECORD_TYPE. This - does not apply to unions. */ + matches the type's size. This generally only applies to RECORD_TYPE. + As an exception, if the union will be passed by reference then it is + acceptable to use the mode of the widest field for the mode of the + union. */ poly_uint64 type_size; - if (TREE_CODE (type) == RECORD_TYPE + if (((TREE_CODE (type) == RECORD_TYPE) + || (TREE_CODE (type) == UNION_TYPE + && targetm.calls.pass_by_reference (pack_cumulative_args (NULL), + mode, type, 0))) && mode != VOIDmode && poly_int_tree_p (TYPE_SIZE (type), &type_size) && known_eq (GET_MODE_BITSIZE (mode), type_size)) The codegen benefits are that the target might have instructions to specifically operate on the partial int mode, which it can use if the mode of the union is set to this partial int mode. So for msp430 if the widest type in a union is __int20 (PSImode), then allowing the union mode to be PSImode results in fewer instructions being used to manipulate the union, compared to if the union mode was SImode. I'll go ahead and test the second patch, unless there is a reason not to allow non-MODE_INT unions. If, for example, we'd rather not have unions be MODE_FLOAT I could always restrict the above logic further to only allow the union mode to be set to a MODE_PARTIAL_INT in addition to the currently allowable MODE_INT.
[Bug testsuite/87694] [9 regression] problem in g++.dg/concepts/memfun-err.C starting with r263343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87694 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-10-22 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Yes. It's a pre-existing thing, my recent patch didn't change that, but I'll fix it.
[Bug testsuite/87694] New: [9 regression] problem in g++.dg/concepts/memfun-err.C starting with r263343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87694
Bug ID: 87694
Summary: [9 regression] problem in g++.dg/concepts/memfun-err.C
starting with r263343
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
Shouldn't this test case be a dg-compile and not a dg-run given it is looking
for compilation errors?
// { dg-do run { target c++17 } }
// { dg-options "-fconcepts" }
UNSUPPORTED: g++.dg/concepts/memfun-err.C -std=gnu++98
UNSUPPORTED: g++.dg/concepts/memfun-err.C -std=gnu++14
Executing on host:
/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++1/../../xg++
-B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++1/../../
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++17 -fconcepts
-L/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-L/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libitm/
-L/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libitm/.libs
-lm -o ./memfun-err.exe(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++1/../../xg++
-B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++1/../../
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++17 -fconcepts
-L/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-L/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libitm/
-L/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libitm/.libs
-lm -o ./memfun-err.exe
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C:27:8:
error: no declaration matches 'void S1::g2() requires (D)()'
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C:23:10:
note: candidate is: 'void S1::g2() requires (C)()'
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C:18:10:
note: 'struct S1' defined here
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C: In
function 'int main()':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C:34:9:
error: no matching function for call to 'S1::f1()'
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C:19:10:
note: candidate: 'void S1::f1() requires (C)() [with T = int]'
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C:19:10:
note: constraints not satisfied
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C:6:16:
note: within 'template concept bool C() [with T = int]'
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C:6:16:
note: 'int' is not a class
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C:35:9:
error: no matching function for call to 'S1::g1()'
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C:20:10:
note: candidate: 'void S1::g1() requires (C)() and true [with T = int]'
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C:20:10:
note: constraints not satisfied
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C:6:16:
note: within 'template concept bool C() [with T = int]'
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C:6:16:
note: 'int' is not a class
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/concepts/memfun-err.C:36:10:
error: no matching function for call to 'S1::h1(int)'
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/c
[Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383 --- Comment #14 from coypu --- Also, after these two patches, my own build of arm--netbsdelf is failing from this: configure: error: Pthreads are required to build libgomp Looking at config.log, the error is actually: configure:15118: /tmp/build/./gcc/xgcc -B/tmp/build/./gcc/ -B/usr/local/arm--netbsdelf/bin/ -B/usr/local/arm--netbsdelf/lib/ -isystem /usr/local/arm--netbsdelf/include -isystem /usr/local/arm--netbsdelf/sys-include --sysroot=/home/fly/shark/destdir.shark/ -o conftest -g -O2 conftest.c -lpthread >&5 /home/fly/shark/destdir.shark/usr/lib/libpthread.so: undefined reference to `__modsi3@GCC_3.0' collect2: error: ld returned 1 exit status I'm not sure what is the cause of that.
[Bug target/87627] GCC generates rube-goldberg machine for trivial tail call on 32-bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87627 --- Comment #5 from Alexander Monakov --- I've spent some time looking at this again, and I couldn't find a way to preserve REG_EQUIV notes (it's actually unclear what REG_EQUIV means precisely). What I think could help in simple cases like this one, and might also be helpful in other situations, is to have mem_attrs indicate that memory does not escape. RTL CSE would not need to invalidate such MEMs when processing a call.
[Bug c/87693] New: ICE in thread_around_empty_blocks, at tree-ssa-threadedge.c:984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87693
Bug ID: 87693
Summary: ICE in thread_around_empty_blocks, at
tree-ssa-threadedge.c:984
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects versions down to at least gcc 5, at -O[s123] :
$ cat z1.c
void f (void);
void g (void);
void h (int a)
{
void *p, **q;
if (a)
p = (void *)f;
else
p = (void *)g;
q = (void *)p;
if (*q == (void *)0)
goto *p;
L0:
return;
}
$ gcc-9-20181021 -c z1.c
$
$ gcc-9-20181021 -c z1.c -O2
during GIMPLE pass: vrp
z1.c: In function 'h':
z1.c:3:6: internal compiler error: Segmentation fault
3 | void h (int a)
| ^
0xa6de1f crash_signal
../../gcc/toplev.c:325
0xc0c3cc thread_around_empty_blocks
../../gcc/tree-ssa-threadedge.c:984
0xc0e010 thread_across_edge
../../gcc/tree-ssa-threadedge.c:1302
0xc0e945 thread_outgoing_edges(basic_block_def*, gcond*, const_and_copies*,
avail_exprs_stack*, evrp_range_analyzer*, tree_node* (*)(gimple*, gimple*,
avail_exprs_stack*, basic_block_def*))
../../gcc/tree-ssa-threadedge.c:1376
0xc81428 vrp_dom_walker::after_dom_children(basic_block_def*)
../../gcc/tree-vrp.c:6508
0x113d094 dom_walker::walk(basic_block_def*)
../../gcc/domwalk.c:395
0xc92e9b identify_jump_threads
../../gcc/tree-vrp.c:6563
0xc92e9b execute_vrp
../../gcc/tree-vrp.c:6699
[Bug fortran/53653] [IR Tracking] Disallow abstract/unlimited-polymorphic types in array constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53653 G. Steinmetz changed: What|Removed |Added CC||gs...@t-online.de --- Comment #2 from G. Steinmetz --- Some reductions : $ cat z1.f90 program p type, abstract :: t end type class(t), allocatable :: x, z(:) allocate (z(1), source=[x]) end $ cat z2.f90 program p type t end type class(t), allocatable :: x, z(:) allocate (z(1), source=[x]) end $ gfortran-9-20181021 -c z2.f90 z2.f90:5:0: 5 |allocate (z(1), source=[x]) | internal compiler error: Segmentation fault 0xb1c86f crash_signal ../../gcc/toplev.c:325 0x5fc806 gfc_add_component_ref(gfc_expr*, char const*) ../../gcc/fortran/class.c:211 0x72dbb7 gfc_trans_allocate(gfc_code*) ../../gcc/fortran/trans-stmt.c:6048 0x6bdb27 trans_code ../../gcc/fortran/trans.c:1990 0x6e51c4 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6505 0x673426 translate_all_program_units ../../gcc/fortran/parse.c:6125 0x673426 gfc_parse_file() ../../gcc/fortran/parse.c:6328 0x6ba3ff gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug fortran/50974] ICE on invalid on function used as variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50974 G. Steinmetz changed: What|Removed |Added CC||gs...@t-online.de --- Comment #4 from G. Steinmetz --- Update : No ICE with a release version 9 to 5, but when configured with --enable-checking=yes. $ cat z1.f90 program p contains real function f() f = g end real function g() end end $ gfortran-9-20181021 -c z1.f90 $ $ gfortran-9-20181021-chk -c z1.f90 z1.f90:3:0: 3 |real function f() | Error: invalid types in conversion to floating point real(kind=4) real(kind=4) (*) (void) _1 = (real(kind=4)) g; z1.f90:3:0: internal compiler error: verify_gimple failed 0xcb79bd verify_gimple_in_seq(gimple*) ../../gcc/tree-cfg.c:5082 0x9e9b55 gimplify_body(tree_node*, bool) ../../gcc/gimplify.c:12859 0x9e9e44 gimplify_function_tree(tree_node*) ../../gcc/gimplify.c:12949 0xd20abf gimplify_all_functions ../../gcc/tree-nested.c:3405 0xd20aaf gimplify_all_functions ../../gcc/tree-nested.c:3408 0xd2a4ee lower_nested_functions(tree_node*) ../../gcc/tree-nested.c:3425 0x827310 cgraph_node::analyze() ../../gcc/cgraphunit.c:673 0x82a799 analyze_functions ../../gcc/cgraphunit.c:1126 0x82b892 symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2833
[Bug middle-end/87692] New: Reuse guard variable for multiple initializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87692
Bug ID: 87692
Summary: Reuse guard variable for multiple initializations
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Consider the following example:
int produce1();
int produce2(int ) noexcept;
auto test() {
static int val1 = produce1();
static int val2 = produce2(val1); // noexcept
return val2 + val2;
}
For the above example two guard variables are generated: for `val1` and `val2`.
However the `val2` initialization always succeeds and may not happen before
`val1` initialization.
So instead of having two variables, `val2` could reuse the guard variable for
`val1`.
Using one variable has advantages: less code is generated and no need in
multiple guard variables checks.
Such optimization will reduce the code size and improve overall performance.
[Bug c++/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87665 --- Comment #6 from Jonathan Wakely --- Since r254694 only changed all -std modes to match -std=c++17 I bisected again using -std=c++17 to find the change that really caused it, and it was indeed r246301 which first removed that null check. However, this isn't the full story, because on x86_64 we generate correct code at r246301 and r254694, even after Ville's changes removed the null check. For x86_64 everything is OK until r255268. Weird.
[Bug c++/85552] Adding curly braces to the declaration of a std::unique_ptr to a forward declared class breaks compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85552 Jonathan Wakely changed: What|Removed |Added CC||tiagomacarios at gmail dot com --- Comment #3 from Jonathan Wakely --- *** Bug 87660 has been marked as a duplicate of this bug. ***
[Bug c++/87660] Fail to compile unique_ptr of incomplete tyoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87660 Jonathan Wakely changed: What|Removed |Added Keywords|rejects-valid | Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- This is a dup *** This bug has been marked as a duplicate of bug 85552 ***
[Bug c++/87680] Small program produces 160 meg .o file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87680
--- Comment #5 from Richard Biener ---
I believe this bug (and other existing dups) are about the C++ FE for array
initializers not emitting a loop for initialization but an initializer for each
element. It does that via
;; Function constexpr Bar::Bar() (null)
;; enabled by -tree-original
{
>>) >;
}
which eventually is gimplified to
Bar::Bar (struct Bar * const this)
{
this->foo[0].a = 10;
this->foo[0].b = 11;
this->foo[0].c = 12;
this->foo[0].d = 13;
this->foo[1].a = 10;
this->foo[1].b = 11;
...
via cp_gimplify_expr.
[Bug c/87691] transparent_union attribute does not work with MODE_PARTIAL_INT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87691 --- Comment #4 from Richard Biener --- What happens if you make the attribute work for a MODE_INT union with a MODE_PARTIAL_INT first field that has MODE_SIZE of the union mode? Is there a generic way to query SImode for PSImode as defined in PARTIAL_INT_MODE (SI, 20, PSI); ? Or does one need to compare MODE_SIZE? Can there be multiple non-partial integer modes with the same size? Thus I suggest to patch handle_transparent_union_attribute according to the above.
[Bug c++/87680] Small program produces 160 meg .o file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87680 --- Comment #4 from Corey Kosak --- To my eye it doesn't seem to be related to exceptions or initializer lists, so I don't think it's the same bug, but you all would know better than me. When I look at the .s file I see a giant sequence of the form .LC0: .long 10 .long 11 .long 12 .long 13 .long 10 .long 11 .long 12 .long 13 .long 10 .long 11 .long 12 .long 13 ... and then the constructor uses .LC0 to initialize the object with a single memcpy. Which might be a fine strategy for objects of reasonable size, but maybe there should be a size cutoff.
[Bug c/87691] transparent_union attribute does not work with MODE_PARTIAL_INT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87691 --- Comment #3 from Jozef Lawrynowicz --- Perhaps it is sufficient to check targetm.pass_by_reference, i.e. if the struct/union with the given mode would be passed by reference, then it is ok to give the struct/union a mode outside the MODE_INT class.
[Bug c/87691] transparent_union attribute does not work with MODE_PARTIAL_INT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87691 --- Comment #2 from Jozef Lawrynowicz --- Created attachment 44880 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44880&action=edit transparent_union.patch
[Bug c/87691] transparent_union attribute does not work with MODE_PARTIAL_INT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87691 --- Comment #1 from Jozef Lawrynowicz --- The issue is that the union is considered to have size of 32 bits (the in-memory size of __int20), so unless mode_for_size as called by compute_record_mode (both in stor-layout.c) is explicitly told to look for a mode of class MODE_PARTIAL_INT, then a size of 32 will always return MODE_INT. In this case, the union will have TYPE_MODE of SImode, but its field is PSImode, so transparent_union has no effect. As was explained on the GCC mailing list (https://gcc.gnu.org/ml/gcc/2018-05/msg00218.html), in general we want to ensure that the class of a union is MODE_INT, as some ABIs mandate that unions be passed in integer registers. For msp430, it is fine to relax this constraint and allow unions to have PSImode, as all general purpose registers are 20-bits (and msp430 doesn't pass structs/unions by value anyway). The attached patch fixes the issue by requesting a mode of class MODE_PARTIAL_INT when calling mode_for_size in compute_record_mode. However, since other targets which support MODE_PARTIAL_INT may want unions to always have class MODE_INT, I wonder if the attached patch is not appropriate. Should there perhaps be a target hook which allows/disallows MODE_PARTIAL_INT structs/unions?
[Bug c/87691] New: transparent_union attribute does not work with MODE_PARTIAL_INT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87691
Bug ID: 87691
Summary: transparent_union attribute does not work with
MODE_PARTIAL_INT
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jozef.l at mittosystems dot com
Target Milestone: ---
msp430-elf uses the partial int type __int20 for pointers in the large memory
model. __int20 has PSImode, with bitsize of 20.
A few DejaGNU tests fail when built with -mlarge for msp430-elf, when
transparent unions are used containing pointers.
These are:
- gcc.c-torture/compile/pr34885.c
- gcc.dg/transparent-union-{1,2,3,4,5}.c
Consider the following C source code:
typedef union {
__int20 a;
} union_a __attribute__ ((__transparent_union__));
Compiling produces a warning:
> msp430-elf-gcc -S testcase.c
> warning: 'transparent_union' attribute ignored [-Wattributes]
[Bug c/87038] diagnostics: Please add warning for jumping over initializers with switch/case in C mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038 --- Comment #20 from Segher Boessenkool --- That is still not what I said, so don't pretend I did please. Those are also not false positives: in all these cases, the program does in fact skip some initialisation. But, it seems -Wjump-misses-init is not what you want; you do not want a warning for jumping over initialisers, it warns for a lot of harmless code. What you want is a warning that only warns if the var is (potentially) used without initialisation?
[Bug target/87690] [RISCV][ABI] GCC fails to sign-extend floats passed in the lp64 ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87690
--- Comment #2 from Alex Bradbury ---
Better example demonstrating the problem exists for returns too:
$ cat foo.c
struct float_struct { float v; };
struct char_struct { char v; };
struct float_struct callee(float, char);
float caller(struct float_struct fs, struct char_struct cs) {
return callee(fs.v, cs.v).v;
}
$ ./riscv32-unknown-elf-gcc -march=rv64i -mabi=lp64 -S -o - foo.c -O2
.file "foo.c"
.option nopic
.text
.align 2
.globl caller
.type caller, @function
caller:
addisp,sp,-16
andia1,a1,0xff
sd ra,8(sp)
callcallee
ld ra,8(sp)
addisp,sp,16
jr ra
.size caller, .-caller
.ident "GCC: (GNU) 9.0.0 20180922 (experimental)"
[Bug target/87690] [RISCV][ABI] GCC fails to sign-extend floats passed in the lp64 ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87690 --- Comment #1 from Alex Bradbury --- It's clear from the example but I made a typo in the explanation due to a last minute change in my example. char is unsigned, so the value in char_struct is zero-extended as we expect.
[Bug target/87690] New: [RISCV][ABI] GCC fails to sign-extend floats passed in the lp64 ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87690
Bug ID: 87690
Summary: [RISCV][ABI] GCC fails to sign-extend floats passed in
the lp64 ABI
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asb at lowrisc dot org
Target Milestone: ---
The RISC-V PSABI documentation specifies the following for the base/integer
calling convention:
1) When passed in registers, scalars narrower than XLEN bits are widened
according to the sign of their type up to 32 bits, then sign-extended to XLEN
bits.
2) Floating-point reals are passed the same way as integers of the same size
3) For aggregates, bits unused due to padding, and bits past the end of an
aggregate whose size in bits is not divisible by XLEN, are undefined.
i.e. when XLEN=64, floats should be sign-extended when passed in GPRs.
In the following example, the top 54 bits in the GPR for char_struct and the
top 32 bits in the GPR for float_struct are undefined. Therefore, the compiler
should insert an explicit sign extension in both cases.
$ cat foo.c
struct float_struct { float v; };
struct char_struct { char v; };
struct float_struct callee(float, char);
struct float_struct caller(struct float_struct fs, struct char_struct cs) {
return callee(fs.v, cs.v);
}
It does for the char, but not for the float. This is not compliant with the
specified ABI:
./riscv32-unknown-elf-gcc -march=rv64i -mabi=lp64 -S -o - foo.c -O2
.file "foo.c"
.option nopic
.text
.align 2
.globl caller
.type caller, @function
caller:
andia1,a1,0xff
tailcallee
.size caller, .-caller
.ident "GCC: (GNU) 9.0.0 20180922 (experimental)"
Note: this is a compiler build from one month ago. I can't see any commits
since then that fix this, and unfortunately I seem unable to build
gas+newlib+gcc in a combined tree currently which I usually do for a rapid
build in order to verify a bug (Error: non-constant .uleb128 is not supported).
[Bug c++/87671] Incorrect debugging information for unique_ptr passed to a constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87671 --- Comment #10 from Tom de Vries --- (In reply to Richard Biener from comment #9) > (In reply to Jonathan Wakely from comment #8) > > There's no such thing as 8.2.2, the next release will be 8.3.0, see > > https://gcc.gnu.org/develop.html#num_scheme > > > > Tom, is it time to backport this from trunk to gcc-7-branch and > > gcc-8-branch? > > Yeah, I think so. Ok, I'm on it.
[Bug rtl-optimization/87678] Redundant vmovss with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87678 --- Comment #2 from Segher Boessenkool --- This is a much more general problem in combine. In general it only tries once, and it only tries the fully simplified form, including known bit values etc.
[Bug fortran/87689] Memory corruption on Power 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689 --- Comment #2 from Judicaël Grasset --- I have tried with gfortran 8.2.0 I have compiled with: gfortran -g main.f doesntwork_p8.f -Wall -Wextra -o exe When running I get: 1 2 3 4 5 0 � foo So it seems the problem still exist. If I add fcheck=all at the compilation, I do not get any run-time error message when executing the program, but the result is still wrong: 1 2 3 4 5 -46855 o foo
[Bug target/87598] [8/9 Regression] Rejects "%a0" with constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87598 --- Comment #7 from Segher Boessenkool --- Author: segher Date: Mon Oct 22 14:03:22 2018 New Revision: 265392 URL: https://gcc.gnu.org/viewcvs?rev=265392&root=gcc&view=rev Log: rs6000: Handle print_operand_address for unexpected RTL (PR87598) As the PR shows, the user can force this to be called on at least some RTL that is not a valid address. Most targets treat this as if the user knows best; let's do the same. PR target/87598 * config/rs6000/rs6000.c (print_operand_address): For unexpected RTL call output_addr_const and hope for the best. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
[Bug target/87598] [8/9 Regression] Rejects "%a0" with constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87598 --- Comment #6 from Segher Boessenkool --- No problem, and thanks for finding and reporting the bug :-) This bug is over 25 years old... I'm committing a fix for the rs6000 part.
[Bug ada/87688] [9.0 regression] ACATS cb1010a cb1010d failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87688 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug middle-end/63155] [6/7 Regression] memory hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155 --- Comment #51 from Richard Biener --- Author: rguenth Date: Mon Oct 22 13:54:23 2018 New Revision: 265390 URL: https://gcc.gnu.org/viewcvs?rev=265390&root=gcc&view=rev Log: 2018-10-22 Steven Bosscher Richard Biener * bitmap.h: Update data structure documentation, including a description of bitmap views as either linked-lists or splay trees. (struct bitmap_element_def): Update comments for splay tree bitmaps. (struct bitmap_head_def): Likewise. (bitmap_list_view, bitmap_tree_view): New prototypes. (bitmap_initialize_stat): Initialize a bitmap_head's indx and tree_form fields. (bmp_iter_set_init): Assert the iterated bitmaps are in list form. (bmp_iter_and_init, bmp_iter_and_compl_init): Likewise. * bitmap.c (bitmap_elem_to_freelist): Unregister overhead of a released bitmap element here. (bitmap_element_free): Remove. (bitmap_elt_clear_from): Work on splay tree bitmaps. (bitmap_list_link_element): Renamed from bitmap_element_link. Move this function similar ones such that linked-list bitmap implementation functions are grouped. (bitmap_list_unlink_element): Renamed from bitmap_element_unlink, and moved for grouping. (bitmap_list_insert_element_after): Renamed from bitmap_elt_insert_after, and moved for grouping. (bitmap_list_find_element): New function spliced from bitmap_find_bit. (bitmap_tree_link_left, bitmap_tree_link_right, bitmap_tree_rotate_left, bitmap_tree_rotate_right, bitmap_tree_splay, bitmap_tree_link_element, bitmap_tree_unlink_element, bitmap_tree_find_element): New functions for splay-tree bitmap implementation. (bitmap_element_link, bitmap_element_unlink, bitmap_elt_insert_after): Renamed and moved, see above entries. (bitmap_tree_listify_from): New function to convert part of a splay tree bitmap to a linked-list bitmap. (bitmap_list_view): Convert a splay tree bitmap to linked-list form. (bitmap_tree_view): Convert a linked-list bitmap to splay tree form. (bitmap_find_bit): Remove. (bitmap_clear, bitmap_clear_bit, bitmap_set_bit, bitmap_single_bit_set_p, bitmap_first_set_bit, bitmap_last_set_bit): Handle splay tree bitmaps. (bitmap_copy, bitmap_count_bits, bitmap_and, bitmap_and_into, bitmap_elt_copy, bitmap_and_compl, bitmap_and_compl_into, bitmap_compl_and_into, bitmap_elt_ior, bitmap_ior, bitmap_ior_into, bitmap_xor, bitmap_xor_into, bitmap_equal_p, bitmap_intersect_p, bitmap_intersect_compl_p, bitmap_ior_and_compl, bitmap_ior_and_compl_into, bitmap_set_range, bitmap_clear_range, bitmap_hash): Reject trying to act on splay tree bitmaps. Make corresponding changes to use linked-list specific bitmap_element manipulation functions as applicable for efficiency. (bitmap_tree_to_vec): New function. (debug_bitmap_elt_file): New function split out from ... (debug_bitmap_file): ... here. Handle splay tree bitmaps. (bitmap_print): Likewise. PR tree-optimization/63155 * tree-ssa-propagate.c (ssa_prop_init): Use tree-view for the SSA edge worklists. * tree-ssa-coalesce.c (coalesce_ssa_name): Populate used_in_copies in tree-view. Modified: trunk/gcc/ChangeLog trunk/gcc/bitmap.c trunk/gcc/bitmap.h trunk/gcc/tree-ssa-coalesce.c trunk/gcc/tree-ssa-propagate.c
[Bug fortran/87689] Memory corruption on Power 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689 Richard Biener changed: What|Removed |Added Target||powerpc64le Status|UNCONFIRMED |WAITING Last reconfirmed||2018-10-22 Version|unknown |7.1.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Please try newer versions like 7.3.0 and provide the compiler options you are using.
[Bug c++/87671] Incorrect debugging information for unique_ptr passed to a constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87671 --- Comment #9 from Richard Biener --- (In reply to Jonathan Wakely from comment #8) > There's no such thing as 8.2.2, the next release will be 8.3.0, see > https://gcc.gnu.org/develop.html#num_scheme > > Tom, is it time to backport this from trunk to gcc-7-branch and gcc-8-branch? Yeah, I think so.
[Bug target/86677] popcount builtin detection is breaking some kernel build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86677
--- Comment #12 from Richard Biener ---
(In reply to Martin Liška from comment #11)
> (In reply to Wilco from comment #10)
> > (In reply to Martin Liška from comment #9)
> > > Taking look at
> > > ../drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c file:
> > >
> > > The __builtin_popcount is generated from:
> > >
> > > static int brcmf_setup_wiphybands(struct brcmf_cfg80211_info *cfg)
> > > {
> > > ...
> > > } else {
> > > for (nchain = 0; rxchain; nchain++)
> > >rxchain = rxchain & (rxchain - 1);
> > > }
> > > ...
> > > }
> > >
> > > It started from r262486. I would that in this situation it's maybe
> > > unexpected that a popcount call will be eventually generated. So I'm for
> > > an
> > > option what will disable the pattern recognition.
> >
> > I'd say this is exactly a case where using a faster popcount instruction
> > helps - if available of course.
>
> Yes, but as seen in PR87528, using a libgcc can slow down a SPEC benchmark.
> But it's related to generic tuning.
>
> >
> > Is there any reason -fno-builtin-popcount can't also block automatic
> > generation of popcount?
>
> Do we really have such option?
None that would work in the way intended.
Note that as I said in the referenced thread a fix could boil down to
adjusting expression_expensive_p to return true if there's no optab
for the builtin/IFN and/or adjusting is_inexpensive_builtin in that way
(with wider effect).
Note that number_of_iterations_popcount might as well create IFN_POPCOUNT
for the case there _is_ an optab. I'm not sure whether we only have/allow
the IFN in case there's an optab.
So let's discuss the efficiency issue in PR87528. PR86677 is really
invalid given you cannot elide providing libgcc.
[Bug target/86677] popcount builtin detection is breaking some kernel build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86677
--- Comment #11 from Martin Liška ---
(In reply to Wilco from comment #10)
> (In reply to Martin Liška from comment #9)
> > Taking look at
> > ../drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c file:
> >
> > The __builtin_popcount is generated from:
> >
> > static int brcmf_setup_wiphybands(struct brcmf_cfg80211_info *cfg)
> > {
> > ...
> > } else {
> > for (nchain = 0; rxchain; nchain++)
> >rxchain = rxchain & (rxchain - 1);
> > }
> > ...
> > }
> >
> > It started from r262486. I would that in this situation it's maybe
> > unexpected that a popcount call will be eventually generated. So I'm for an
> > option what will disable the pattern recognition.
>
> I'd say this is exactly a case where using a faster popcount instruction
> helps - if available of course.
Yes, but as seen in PR87528, using a libgcc can slow down a SPEC benchmark. But
it's related to generic tuning.
>
> Is there any reason -fno-builtin-popcount can't also block automatic
> generation of popcount?
Do we really have such option?
[Bug c++/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87665 --- Comment #5 from Jonathan Wakely --- Confirmed that -fcheck-null fixes the miscompilation.
[Bug fortran/87689] New: Memory corruption on Power 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689 Bug ID: 87689 Summary: Memory corruption on Power 8 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: judicael.grasset at stfc dot ac.uk Target Milestone: --- Hello, I am compiling this code with gfortran 7.1.0 on a power 8 machine: main.f: program main implicit none character :: c character(len=20) :: res, doesntwork_p8 external doesntwork_p8 c = 'o' res = doesntwork_p8(c,1,2,3,4,5,6) write(*,*)res end program main doesnwork_p8.f: function doesntwork_p8(c,a1,a2,a3,a4,a5,a6) implicit none character(len=20) :: doesntwork_p8 character :: c integer :: a1,a2,a3,a4,a5,a6 write(*,*)a1,a2,a3,a4,a5,a6 write(*,*)c doesntwork_p8 = 'foo' return end And when I run it, it prints: 1 2 3 4 5 0 � foo But I expect: 1 2 3 4 5 6 o foo Also if compiled with fcheck=all, a runtime message say: At line 1 of file doesntwork_p8.f Fortran runtime error: Actual string length is shorter than the declared one for dummy argument 'c' (0/1) gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/gpfs/paragon/local/apps/gcc/gcc/7.1.0/bin/../libexec/gcc/powerpc64le-unknown-linux-gnu/7.1.0/lto-wrapper Target: powerpc64le-unknown-linux-gnu Configured with: ./configure --prefix=/gpfs/panther/local/apps/gcc/gcc/7.1.0 --enable-languages=c,c++,fortran --disable-multilib --disable-bootstrap --with-system-zlib --enable-__cxa_atexit --disable-nls --disable-linux-futex Thread model: posix gcc version 7.1.0 (GCC)
[Bug c++/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87665 Jonathan Wakely changed: What|Removed |Added CC||ville at gcc dot gnu.org Target Milestone|8.3 |--- --- Comment #4 from Jonathan Wakely --- Bisecting on powerpc64le shows it regressed with r254694 which makes a bit more sense (as std::vector reallocation does use placement new to move the values): Remove the null check from placement new in all modes gcc/cp/ Remove the null check from placement new in all modes * init.c (build_new_1): Don't do a null check for a namespace-scope non-replaceable placement new in any mode unless -fcheck-new is provided. testsuite/ Remove the null check from placement new in all modes * g++.dg/init/pr35878_1.C: Adjust. * g++.dg/init/pr35878_4.C: New. * g++.dg/torture/pr48695.C: Adjust. * g++.dg/tree-ssa/pr31146-2.C: Likewise. * g++.dg/tree-ssa/pr41428.C: Adjust.
[Bug target/86677] popcount builtin detection is breaking some kernel build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86677
--- Comment #10 from Wilco ---
(In reply to Martin Liška from comment #9)
> Taking look at
> ../drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c file:
>
> The __builtin_popcount is generated from:
>
> static int brcmf_setup_wiphybands(struct brcmf_cfg80211_info *cfg)
> {
> ...
> } else {
> for (nchain = 0; rxchain; nchain++)
>rxchain = rxchain & (rxchain - 1);
> }
> ...
> }
>
> It started from r262486. I would that in this situation it's maybe
> unexpected that a popcount call will be eventually generated. So I'm for an
> option what will disable the pattern recognition.
I'd say this is exactly a case where using a faster popcount instruction helps
- if available of course.
Is there any reason -fno-builtin-popcount can't also block automatic generation
of popcount?
[Bug tree-optimization/87686] [9 regression] internal error in expand, at tree-switch-conversion.c:916
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87686 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška --- Fixed.
[Bug c++/87671] Incorrect debugging information for unique_ptr passed to a constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87671 --- Comment #8 from Jonathan Wakely --- There's no such thing as 8.2.2, the next release will be 8.3.0, see https://gcc.gnu.org/develop.html#num_scheme Tom, is it time to backport this from trunk to gcc-7-branch and gcc-8-branch?
[Bug c++/87671] Incorrect debugging information for unique_ptr passed to a constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87671 --- Comment #7 from Anton Barkovsky --- (In reply to Jonathan Wakely from comment #6) > That does seem to explain the difference. With GCC 8 GDB thinks that 'ptr' > is passed in the register %rsi so the value in the register is the value of > the unique_ptr's member. With GCC 9 it correctly knows that the param is > passed by invisible reference, and so the value in the register is the > address of the unique_ptr on the stack. > > This was fixed on trunk by r263164 so is a dup of PR 86687 > > *** This bug has been marked as a duplicate of bug 86687 *** Thank you very much for the timely analysis. Is there a chance this fix will be backported to 8.2.2? This is quite disruptive for development.
[Bug tree-optimization/87686] [9 regression] internal error in expand, at tree-switch-conversion.c:916
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87686 --- Comment #3 from Martin Liška --- Author: marxin Date: Mon Oct 22 13:09:33 2018 New Revision: 265388 URL: https://gcc.gnu.org/viewcvs?rev=265388&root=gcc&view=rev Log: Revert r263947. 2018-10-22 Martin Liska PR tree-optimization/87686 Revert 2018-08-29 Martin Liska * tree-switch-conversion.c (switch_conversion::expand): Strenghten assumption about gswitch statements. 2018-10-22 Martin Liska PR tree-optimization/87686 * g++.dg/tree-ssa/pr87686.C: New test. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr87686.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-switch-conversion.c
[Bug debug/86687] Wrong debug information for string types passed as parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86687 Jonathan Wakely changed: What|Removed |Added CC||anton at swarmer dot me --- Comment #14 from Jonathan Wakely --- *** Bug 87671 has been marked as a duplicate of this bug. ***
[Bug c++/87671] Incorrect debugging information for unique_ptr passed to a constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87671 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Jonathan Wakely --- That does seem to explain the difference. With GCC 8 GDB thinks that 'ptr' is passed in the register %rsi so the value in the register is the value of the unique_ptr's member. With GCC 9 it correctly knows that the param is passed by invisible reference, and so the value in the register is the address of the unique_ptr on the stack. This was fixed on trunk by r263164 so is a dup of PR 86687 *** This bug has been marked as a duplicate of bug 86687 ***
[Bug target/86677] popcount builtin detection is breaking some kernel build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86677
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #9 from Martin Liška ---
Taking look at ../drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
file:
The __builtin_popcount is generated from:
static int brcmf_setup_wiphybands(struct brcmf_cfg80211_info *cfg)
{
...
} else {
for (nchain = 0; rxchain; nchain++)
rxchain = rxchain & (rxchain - 1);
}
...
}
It started from r262486. I would that in this situation it's maybe unexpected
that a popcount call will be eventually generated. So I'm for an option what
will disable the pattern recognition.
[Bug ada/87688] [9.0 regression] ACATS cb1010a cb1010d failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87688 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-22 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed, it appeared between revisions r264819 (OK) and r264901 (FAIL).
[Bug ada/87688] New: [9.0 regression] ACATS cb1010a cb1010d failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87688 Bug ID: 87688 Summary: [9.0 regression] ACATS cb1010a cb1010d failure Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org Target Milestone: --- Host: x86_64-apple-darwin15 Created attachment 44879 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44879&action=edit Extract from acats suite With r265267, the two tests noted fail. OK with r264669. The build command is (effectively) gnatmake -gnatws -O2 -gnat95 -fstack-check cb1010a.adb and the output is ,.,. CB1010A ACATS 2.5 18-10-19 17:40:00 CB1010A CHECK THAT STORAGE_ERROR IS RAISED WHEN STORAGE ALLOCATED TO A TASK IS EXCEEDED. - CB1010A CHECK TASKS THAT DO NOT HANDLE STORAGE_ERROR PRIOR TO RENDEZVOUS. raised STORAGE_ERROR : stack overflow Should be: ,.,. CB1010A ACATS 4.1 18-10-22 11:15:25 CB1010A CHECK THAT STORAGE_ERROR IS RAISED WHEN STORAGE ALLOCATED TO A TASK IS EXCEEDED. - CB1010A CHECK TASKS THAT DO NOT HANDLE STORAGE_ERROR PRIOR TO RENDEZVOUS. - CB1010A CHECK TASKS THAT DO HANDLE STORAGE_ERROR PRIOR TO RENDEZVOUS. - CB1010A CHECK TASKS THAT DO NOT HANDLE STORAGE_ERROR DURING RENDEZVOUS. CB1010A PASSED . Removing either -O2 or -fstack-check makes the tests execute correctly. (Note, the build was configured --without-isl because of PR87640, now fixed.)
[Bug c++/87676] Presence of variadic constructor template breaks overload resolution for other constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87676
--- Comment #6 from Harald van Dijk ---
(In reply to Jonathan Wakely from comment #4)
> Before the conversion sequence that binds a reference you need to initialize
> the underlying temporary, which is a list-initialization sequence. You have
> list-initialization sequence L1 from {1,2,3} to S1 and list-initialization
> sequence L2 from {1,2,3} to S2. Neither L1 nor L2 is better than the other
> according to http://eel.is/c++draft/over.match.best#over.ics.rank-3.1
True, which is why I think it falls back to the subsequent binding to the
temporary. If you take an ambiguous list-init sequence as sufficient reason to
not look at the rest, then would not even
struct S {};
void f(const S &);
void f(S &&);
void g() { f({}); }
be ambiguous? Both start with the same list-init sequence, so neither is better
than the other. But here, GCC does look beyond that and prefer f(S &&).
I'll be happy to agree that the standard isn't clear, and that I might well be
wrong.
[Bug c++/87671] Incorrect debugging information for unique_ptr passed to a constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87671 --- Comment #5 from Jonathan Wakely --- Compiled with GCC 8 the debuginfo has: DW_TAG_formal_parameter DW_AT_abstract_origin (0x3cfb "ptr") DW_AT_location( [0x, 0x0010): DW_OP_reg4 RSI [0x0010, 0x007b): 01 54 9f) Compiled with GCC 9: DW_TAG_formal_parameter DW_AT_abstract_origin (0x3cfb "ptr") DW_AT_location( [0x, 0x0010): DW_OP_breg4 RSI+0 [0x0010, 0x007b): 01 54) That's the only difference I see in the outputs of `llvm-dwarfdump --diff`.
[Bug tree-optimization/87613] Non-reachable default required in switch statement to get optimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87613
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |WORKSFORME
--- Comment #2 from Martin Liška ---
Yes, it was fixed by Jakub in GCC 8 in r247538. As Richi said, to suppress the
warning, please use __builtin_unreachable () like:
template int foo();
typedef int (*int_fun)();
inline int_fun get_fun(unsigned int x)
{
switch(x&7)
{
case 0: return foo<0>;
case 1: return foo<1>;
case 2: return foo<2>;
case 3: return foo<3>;
case 4: return foo<4>;
case 5: return foo<5>;
case 6: return foo<6>;
case 7: return foo<7>;
default: __builtin_unreachable (); // never happens
}
// alternative to default case:
// return 0; // never happens
}
int bla(unsigned int x)
{
return get_fun(x)();
}
[Bug c++/87676] Presence of variadic constructor template breaks overload resolution for other constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87676 --- Comment #5 from Jonathan Wakely --- That's how I interpret it anyway, but I could be convinced otherwise. And maybe the standard isn't clear enough here.
[Bug c++/87676] Presence of variadic constructor template breaks overload resolution for other constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87676
--- Comment #4 from Jonathan Wakely ---
Before the conversion sequence that binds a reference you need to initialize
the underlying temporary, which is a list-initialization sequence. You have
list-initialization sequence L1 from {1,2,3} to S1 and list-initialization
sequence L2 from {1,2,3} to S2. Neither L1 nor L2 is better than the other
according to http://eel.is/c++draft/over.match.best#over.ics.rank-3.1
[Bug bootstrap/87640] [9 regression] internal compiler error: in check, at tree-vrp.c:155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87640 Richard Biener changed: What|Removed |Added CC||iii at linux dot ibm.com --- Comment #12 from Richard Biener --- *** Bug 87687 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/87687] s390x gcc 9 ICE in value_range::check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87687 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Richard Biener --- dup *** This bug has been marked as a duplicate of bug 87640 ***
[Bug c++/87667] -Wformat + typed enum class - difference with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87667 --- Comment #3 from Jonathan Wakely --- I think the warning is correct. A scoped enumeration type is not subject to integral promotion, so the argument is not promoted to int. When the body of printf tries to read an int from the argument the behaviour is undefined.
[Bug web/87684] -Woverloaded-virtual is not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87684 --- Comment #4 from Daniel Fruzynski --- Thanks for the link. I have tried to google for "gcc Woverloaded-virtual" and it did not show on the top, so I assumed that option is undocumented. I will open new issue to add it to -Wall.
[Bug tree-optimization/87687] New: s390x gcc 9 ICE in value_range::check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87687
Bug ID: 87687
Summary: s390x gcc 9 ICE in value_range::check
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: iii at linux dot ibm.com
Target Milestone: ---
Target: s390x-redhat-linux
SVN r265373 / git f9fd74d64e9:
$ f9fd74d64e9-install/bin/gcc -x c -O2 -c -
void b() {
int c = 1, d, e = 4096;
for (; c; c--) {
d = 1;
for (; d; d--)
e--;
}
}
during GIMPLE pass: evrp
: In function ‘b’:
:8:1: internal compiler error: in check, at tree-vrp.c:155
0x1ab6019 value_range::check()
/home/iii/ibm/gcc-bisect/src/gcc/tree-vrp.c:155
0x1ab9a35 value_range::value_range(value_range_kind, tree_node*, tree_node*,
bitmap_head*)
/home/iii/ibm/gcc-bisect/src/gcc/tree-vrp.c:110
0x1ab9a35 set_value_range_with_overflow
/home/iii/ibm/gcc-bisect/src/gcc/tree-vrp.c:1422
0x1ab9a35 extract_range_from_binary_expr_1(value_range*, tree_code, tree_node*,
value_range const*, value_range const*)
/home/iii/ibm/gcc-bisect/src/gcc/tree-vrp.c:1679
0x1b48af7 vr_values::extract_range_from_binary_expr(value_range*, tree_code,
tree_node*, tree_node*, tree_node*)
/home/iii/ibm/gcc-bisect/src/gcc/vr-values.c:734
0x1b4b0d1 vr_values::extract_range_from_assignment(value_range*, gassign*)
/home/iii/ibm/gcc-bisect/src/gcc/vr-values.c:1389
0x1f03e29 evrp_range_analyzer::record_ranges_from_stmt(gimple*, bool)
/home/iii/ibm/gcc-bisect/src/gcc/gimple-ssa-evrp-analyze.c:285
0x1f0228f evrp_dom_walker::before_dom_children(basic_block_def*)
/home/iii/ibm/gcc-bisect/src/gcc/gimple-ssa-evrp.c:139
0x1edb47d dom_walker::walk(basic_block_def*)
/home/iii/ibm/gcc-bisect/src/gcc/domwalk.c:353
0x1f02dc9 execute_early_vrp
/home/iii/ibm/gcc-bisect/src/gcc/gimple-ssa-evrp.c:311
0x1f02dc9 execute
/home/iii/ibm/gcc-bisect/src/gcc/gimple-ssa-evrp.c:348
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/87686] [9 regression] internal error in expand, at tree-switch-conversion.c:916
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87686 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from Martin Liška --- Started with r263947, which is where I added just a new assert.
[Bug target/87674] AVX512: incorrect intrinsic signature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87674 --- Comment #3 from Wenzel Jakob --- Thanks -- this patch works for me. With regards to the signature difference: I had already stumbled about the (float *) vs (some value *) difference in some intrinsics. In the best case differences cause warnings (ok, but still annoying :)), in the worst case special casts are needed for GCC, making intrinsics code less portable between compilers. So my vote would definitely matching ICC behavior 1:1.
[Bug tree-optimization/87686] [9 regression] internal error in expand, at tree-switch-conversion.c:916
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87686 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-22 CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Mine.
[Bug tree-optimization/87686] [9 regression] internal error in expand, at tree-switch-conversion.c:916
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87686 Richard Biener changed: What|Removed |Added CC||mliska at suse dot cz Target Milestone|--- |9.0
[Bug c++/87676] Presence of variadic constructor template breaks overload resolution for other constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87676
--- Comment #3 from Harald van Dijk ---
(In reply to Jonathan Wakely from comment #1)
> The template constructor allows s({1, 2, 3}) to mean s(S2{1,2,3}) which
> tries to use the deleted copy constructor.
Thanks, I think you're right about that. The diagnostic didn't help me
understand what was going on, but now that I do understand it, I do not see how
it could be improved.
But all other things equal, aren't rvalue reference overloads preferred over
lvalue reference overloads, so shouldn't S1 && still be preferred over const S2
&? That appears to be the logic Intel is using, and in a similar example,
struct S1 {};
struct S2 {};
void f(const S1 &);
void f(S2 &&);
void g() { f({}); }
clang does agree that this calls f(S2 &&) as well, but GCC still rejects it as
ambiguous.
The relevant bit in the standard seems to be [over.ics.rank]p3.2.3
: (yes, I know it's a draft, but
this text is also present in the actual standard)
> - Standard conversion sequence S1 is a better conversion sequence than
> standard conversion sequence S2 if
> [...]
> - S1 and S2 are reference bindings and neither refers to an implicit object
> parameter of a non-static member function declared without a ref-qualifier,
> and S1 binds an rvalue reference to an rvalue and S2 binds an lvalue reference
This appears to not just disambiguate between lvalue and rvalue references to
the same type, it also disambiguates between lvalue and rvalue references to
different types.
[Bug c/87682] gcc/mem-stats.h:172: possible broken comparison operator ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87682 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug c/87682] gcc/mem-stats.h:172: possible broken comparison operator ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87682 --- Comment #2 from Richard Biener --- Author: rguenth Date: Mon Oct 22 10:25:28 2018 New Revision: 265376 URL: https://gcc.gnu.org/viewcvs?rev=265376&root=gcc&view=rev Log: 2018-10-22 Richard Biener PR middle-end/87682 * mem-stats.h (mem_usage::operator==): Fix pasto. Modified: trunk/gcc/ChangeLog trunk/gcc/mem-stats.h
[Bug bootstrap/87640] [9 regression] internal compiler error: in check, at tree-vrp.c:155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87640 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Richard Biener --- Fixed.
[Bug bootstrap/87640] [9 regression] internal compiler error: in check, at tree-vrp.c:155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87640 --- Comment #10 from Richard Biener --- Author: rguenth Date: Mon Oct 22 10:22:48 2018 New Revision: 265375 URL: https://gcc.gnu.org/viewcvs?rev=265375&root=gcc&view=rev Log: 2018-10-22 Richard Biener PR tree-optimization/87640 * tree-vrp.c (set_value_range_with_overflow): Decompose incomplete result. (extract_range_from_binary_expr_1): Adjust. * gcc.dg/torture/pr87640.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr87640.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug fortran/87495] Warning: ‘fastcall’ attribute ignored [-Wattributes] for !GCC$ ATTRIBUTES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87495
--- Comment #10 from Martin Liška ---
(In reply to rguent...@suse.de from comment #8)
> On Mon, 22 Oct 2018, marxin at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87495
> >
> > Martin Liška changed:
> >
> >What|Removed |Added
> >
> > Status|WAITING |REOPENED
> >
> > --- Comment #7 from Martin Liška ---
> > OK, the fastcall is a special one, but I see it for all of:
> >
> > const ext_attr_t ext_attr_list[] = {
> > { "dllimport",EXT_ATTR_DLLIMPORT,"dllimport" },
> > { "dllexport",EXT_ATTR_DLLEXPORT,"dllexport" },
> > { "cdecl",EXT_ATTR_CDECL,"cdecl" },
> > { "stdcall", EXT_ATTR_STDCALL, "stdcall" },
> > { "fastcall", EXT_ATTR_FASTCALL, "fastcall" },
> > { "no_arg_check", EXT_ATTR_NO_ARG_CHECK, NULL},
> > { NULL, EXT_ATTR_LAST, NULL}
> > };
> >
> > gfortran f.f90
> > f.f90:1:0:
> >
> > elemental real function sin(arg)
> >
> > Warning: ‘cdecl’ attribute ignored [-Wattributes]
>
> But that's in the same ballpark. All of them seem to be...
> (just check on a C testcase with -Wall).
Ah, sorry, now I see it!
[Bug tree-optimization/87686] New: [9 regression] internal error in expand, at tree-switch-conversion.c:916
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87686
Bug ID: 87686
Summary: [9 regression] internal error in expand, at
tree-switch-conversion.c:916
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ebotcazou at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-linux
Created attachment 44878
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44878&action=edit
Testcase
It's a doubly-reduced testcase (reduced for this PR after having being reduced
for another issue) so it might be borderline, but it should not ICE anyway:
t.cpp: In member function 'k k::l()':
t.cpp:16:18: warning: no return statement in function returning non-void
[-Wreturn-type]
16 | k l() { j.i(); }
| ^
t.cpp: In member function 'a a::i()':
t.cpp:12:3: warning: control reaches end of non-void function [-Wreturn-type]
12 | }
| ^
during GIMPLE pass: switchconv
t.cpp: In member function 'k k::l()':
t.cpp:18:22: internal compiler error: in expand, at
tree-switch-conversion.c:916
18 | void m(k h) { h.l(); }
| ^
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug fortran/87495] Warning: ‘fastcall’ attribute ignored [-Wattributes] for !GCC$ ATTRIBUTES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87495 Dominique d'Humieres changed: What|Removed |Added Status|REOPENED|NEW --- Comment #9 from Dominique d'Humieres --- This PR has never been closed.
[Bug fortran/87495] Warning: ‘fastcall’ attribute ignored [-Wattributes] for !GCC$ ATTRIBUTES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87495
--- Comment #8 from rguenther at suse dot de ---
On Mon, 22 Oct 2018, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87495
>
> Martin Liška changed:
>
>What|Removed |Added
>
> Status|WAITING |REOPENED
>
> --- Comment #7 from Martin Liška ---
> OK, the fastcall is a special one, but I see it for all of:
>
> const ext_attr_t ext_attr_list[] = {
> { "dllimport",EXT_ATTR_DLLIMPORT,"dllimport" },
> { "dllexport",EXT_ATTR_DLLEXPORT,"dllexport" },
> { "cdecl",EXT_ATTR_CDECL,"cdecl" },
> { "stdcall", EXT_ATTR_STDCALL, "stdcall" },
> { "fastcall", EXT_ATTR_FASTCALL, "fastcall" },
> { "no_arg_check", EXT_ATTR_NO_ARG_CHECK, NULL},
> { NULL, EXT_ATTR_LAST, NULL}
> };
>
> gfortran f.f90
> f.f90:1:0:
>
> elemental real function sin(arg)
>
> Warning: ‘cdecl’ attribute ignored [-Wattributes]
But that's in the same ballpark. All of them seem to be...
(just check on a C testcase with -Wall).
[Bug fortran/87495] Warning: ‘fastcall’ attribute ignored [-Wattributes] for !GCC$ ATTRIBUTES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87495
Martin Liška changed:
What|Removed |Added
Status|WAITING |REOPENED
--- Comment #7 from Martin Liška ---
OK, the fastcall is a special one, but I see it for all of:
const ext_attr_t ext_attr_list[] = {
{ "dllimport",EXT_ATTR_DLLIMPORT,"dllimport" },
{ "dllexport",EXT_ATTR_DLLEXPORT,"dllexport" },
{ "cdecl",EXT_ATTR_CDECL,"cdecl" },
{ "stdcall", EXT_ATTR_STDCALL, "stdcall" },
{ "fastcall", EXT_ATTR_FASTCALL, "fastcall" },
{ "no_arg_check", EXT_ATTR_NO_ARG_CHECK, NULL},
{ NULL, EXT_ATTR_LAST, NULL}
};
gfortran f.f90
f.f90:1:0:
elemental real function sin(arg)
Warning: ‘cdecl’ attribute ignored [-Wattributes]
[Bug c++/87671] Incorrect debugging information for unique_ptr passed to a constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87671
--- Comment #4 from Jonathan Wakely ---
The problem is that GDB sees a stack address for the int* member of the
unique_ptr, but it should be a pointer to the 'int' on the heap:
Breakpoint 1, A::A (this=0x7fffd2b7, ptr=std::unique_ptr = {...}) at
up.cc:7
(gdb) p &ptr
$6 = (std::unique_ptr > *) 0x7fffd290
(gdb) p ptr._M_t._M_t._M_head_impl
$7 = (int *) 0x7fffd2b8
The Incorrect value for *ptr is just because it dereferences that bad address.
If you step into the operator* function you see that the right address is
returned from get()
(gdb) step
std::unique_ptr >::operator*
(this=0x7fffd2b8) at
/home/jwakely/gcc/8/include/c++/8.2.1/bits/unique_ptr.h:329
std::unique_ptr >::get (this=0x7fffd2b8) at
/home/jwakely/gcc/8/include/c++/8.2.1/bits/unique_ptr.h:343
(gdb) finish
Run till exit from #0 std::unique_ptr >::get
(this=0x7fffd2b8) at
/home/jwakely/gcc/8/include/c++/8.2.1/bits/unique_ptr.h:343
std::unique_ptr >::operator*
(this=0x7fffd2b8) at
/home/jwakely/gcc/8/include/c++/8.2.1/bits/unique_ptr.h:330
Value returned is $8 = (int *) 0x614e70
(gdb) p *$8
$9 = 42
I don't know why GDB sees a bad value for the unique_ptr's data member.
[Bug c++/87667] -Wformat + typed enum class - difference with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87667 --- Comment #2 from Roman Lebedev --- (In reply to Jonathan Wakely from comment #1) > It's a warning, why do you think either compiler is wrong? Either it is incorrect to pass `enum class Enum : unsigned short` when the format specifier is %hx (i.e. `unsigned short`), and then the warning is justified; or the other way around, it is correct to pass `Enum`, and the warning is not justified, or needs different wording.
[Bug c++/87685] [8/9 Regression] Calling a static method from inside a generic lambda requires to capture 'this'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87685 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-22 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |8.3 Summary|[Regression] Calling a |[8/9 Regression] Calling a |static method from inside a |static method from inside a |generic lambda requires to |generic lambda requires to |capture 'this' |capture 'this' Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r251438.
[Bug c++/87671] Incorrect debugging information for unique_ptr passed to a constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87671 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-22 Known to work||9.0 Ever confirmed|0 |1 Known to fail||4.9.4, 5.5.0, 6.4.0, 7.3.0, ||8.2.0 --- Comment #3 from Jonathan Wakely --- I see this with old releases but not on current trunk.
[Bug c++/87667] -Wformat + typed enum class - difference with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87667 --- Comment #1 from Jonathan Wakely --- It's a warning, why do you think either compiler is wrong?
[Bug libstdc++/87666] Memory access errors when using c++ 17 filesystem library and "-mcpu=cortex-a53"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87666 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- I think this is caused by inconsistent values of the __gnu_cxx::__default_lock_policy constant in the code in libstdc++fs.a and your object file, caused by the different -march option. *** This bug has been marked as a duplicate of bug 67843 ***
[Bug libstdc++/67843] experimental/filesystem/iterators/directory_iterator.cc fails on armv5t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67843 Jonathan Wakely changed: What|Removed |Added CC||christian_hoff at gmx dot net --- Comment #10 from Jonathan Wakely --- *** Bug 87666 has been marked as a duplicate of this bug. ***
