[Bug tree-optimization/89027] [9 Regression] ICE: verify_gimple failed (Error: non-trivial conversion at assignment)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89027 Martin Liška changed: What|Removed |Added Last reconfirmed||2019-1-24 CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Known to work||8.2.0 Target Milestone|--- |9.0 Known to fail||9.0 --- Comment #1 from Martin Liška --- Confirmed, started with r268067.
[Bug sanitizer/89010] Update URLs in libsanitizer/README.gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89010 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Liška --- Closing.
[Bug c/89015] [9 Regression] ICE in lookup_decl_in_outer_ctx, at omp-low.c:3480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89015 Martin Liška changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-24 CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||9.0 --- Comment #2 from Martin Liška --- Started with r265930, rejected with GCC 8.
[Bug tree-optimization/89002] [7/8/9 Regression] ICE in scan_omp_1_op, at omp-low.c:3166
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89002 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-24 CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with r228777.
[Bug gcov-profile/88994] [GCOV] encoding (or unicode) error with gcov/gcc9 when generating filename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88994 --- Comment #7 from Martin Liška --- Author: marxin Date: Thu Jan 24 08:27:39 2019 New Revision: 268233 URL: https://gcc.gnu.org/viewcvs?rev=268233&root=gcc&view=rev Log: Fix broken filename for .gcda files starting with '..' (PR gcov-profile/88994). 2019-01-24 Martin Liska PR gcov-profile/88994 * gcov-io.c (mangle_path): Do not allocate a bigger buffer, result will be always smaller or equal to the original. * gcov.c (mangle_name): Fix else branch where we should also copy to PTR and shift the pointer. Modified: trunk/gcc/ChangeLog trunk/gcc/gcov-io.c trunk/gcc/gcov.c
[Bug tree-optimization/88713] Vectorized code slow vs. flang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713 --- Comment #51 from rguenther at suse dot de --- On Thu, 24 Jan 2019, tkoenig at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713 > > --- Comment #49 from Thomas Koenig --- > (In reply to Uroš Bizjak from comment #48) > > (In reply to rguent...@suse.de from comment #47) > > > >But why don't we generate sqrtps for vector sqrtf? > > > > > > That's the default for - mrecip back in time we benchmarked it and scalar > > > recip miscompares sth. > > > > It was polyhedron benchmark, in one benchmark, the index was calculated from > > square root, and that was too sensitive for 2 ULP difference. > > Argh. Sacrificing performance for the sake of bugware... Maybe use of FMA can recover 1 ULP and the benchmark ;)
[Bug gcov-profile/88994] [GCOV] encoding (or unicode) error with gcov/gcc9 when generating filename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88994 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Martin Liška --- Fixed.
[Bug c/89031] New: Should not report unused result when explicitly cast to void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89031 Bug ID: 89031 Summary: Should not report unused result when explicitly cast to void Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: porton at narod dot ru Target Milestone: --- GCC reports unused result even when explicitly converted to void to show the developer's intent not to report a warning. lib.c: In function ‘libcomcom_run_command’: lib.c:263:15: error: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Werror=unused-result] (void)write(process.child[WRITE_END], &errno, sizeof(errno)); /* deliberately don't check error */ ^~ cc1: all warnings being treated as errors Should not report unused result when explicitly cast to void.
[Bug gcov-profile/89000] gcov --function-summaries says No branches/No calls, only the File summary is correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89000 --- Comment #3 from Martin Liška --- > > We downgraded our toolchain to 7.4 because our process currently expects the > gcov output to be consistent with previous output from our heritage > baseline. We do need the output, and ideally it would be part of the -f > option as in the past, but we could pull the data from the intermediate > format, as you suggested, so once that is available we would be interested > in reviewing it for adoption into our process and tools. Thanks for your > quick response. I would definitely recommend the intermediate format that will be reworked in GCC 9.1 release. It should provide more stable format in a JSON format. Please take a look: https://gcc.gnu.org/onlinedocs/gcc/Invoking-Gcov.html#Invoking-Gcov (--json-format).
[Bug web/89032] New: Missing documentation for GCC 7.4.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89032 Bug ID: 89032 Summary: Missing documentation for GCC 7.4.0 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Following url (mentioned https://gcc.gnu.org/gcc-7/) is missing: https://gcc.gnu.org/onlinedocs/7.4.0/
[Bug tree-optimization/89027] [9 Regression] ICE: verify_gimple failed (Error: non-trivial conversion at assignment)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89027 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- -mvsx isn't needed, ICEs on x86_64 with those options too. The problem is that shrink_simd_arrays shrinks the array types of the magic simd array variables, but the code doesn't expect that there is anything refering to the whole arrays; until recently that has been the case, now there can be CLOBBERs that would need adjustment, but shrink_simd_arrays doesn't really walk the whole IL so that it would be easy to find them and fix them. Guess easiest would be not to add clobbers for the simd array variables.
[Bug middle-end/89015] [9 Regression] ICE in lookup_decl_in_outer_ctx, at omp-low.c:3480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89015 Richard Biener changed: What|Removed |Added Keywords||openmp Component|c |middle-end Target Milestone|--- |9.0
[Bug c/89031] Should not report unused result when explicitly cast to void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89031 --- Comment #1 from Andrew Pinski --- This attribute is documented this way. I know there are a few duplicates of this bug already filed too.
[Bug tree-optimization/88713] Vectorized code slow vs. flang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713 --- Comment #52 from Marc Glisse --- (In reply to Thomas Koenig from comment #49) > Argh. Sacrificing performance for the sake of bugware... But note that in this PR (specifically for avx512 vectors on this cpu), the OP says that the recip version is slower than calling directly the right insn (it wasn't clear if that was for inverse or for sqrt).
[Bug tree-optimization/89018] common subexpression present in both branches of condition is not factored out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89018 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-24 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- fold does/did some of these transforms (not for the call case). There's tail merging on GIMPLE and cross-jumping on RTL as well as ifcvt/phiopt that in theory could handle all cases. There's also code sinking that could be massaged (like I massaged it to common stores). It doesn't really fit very well anywhere though (phiopt comes closest I think, as "pre"-pass to the other transforms, emptying the middle blocks as much as possible). [local count: 1073741824]: if (a_2(D) >= b_3(D)) goto ; [50.00%] else goto ; [50.00%] [local count: 536870913]: iftmp.0_4 = -a_2(D); goto ; [100.00%] [local count: 536870913]: iftmp.0_5 = -b_3(D); [local count: 1073741824]: # iftmp.0_1 = PHI return iftmp.0_1; .. [local count: 1073741824]: if (a_3(D) >= b_4(D)) goto ; [50.00%] else goto ; [50.00%] [local count: 536870913]: iftmp.2_7 = transform (a_3(D)); goto ; [100.00%] [local count: 536870913]: iftmp.2_9 = transform (b_4(D)); [local count: 1073741824]: # iftmp.2_1 = PHI return iftmp.2_1;
[Bug tree-optimization/88713] Vectorized code slow vs. flang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713 --- Comment #53 from rguenther at suse dot de --- On Thu, 24 Jan 2019, glisse at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713 > > --- Comment #52 from Marc Glisse --- > (In reply to Thomas Koenig from comment #49) > > Argh. Sacrificing performance for the sake of bugware... > > But note that in this PR (specifically for avx512 vectors on this cpu), the OP > says that the recip version is slower than calling directly the right insn (it > wasn't clear if that was for inverse or for sqrt). Probably depends on the microarchitecture, yes. But I'd fully expect the two-NR step variant to be slower for a sensible HW implementation (even more so if we need to fend off the exceptional cases)
[Bug target/89021] Implement mmintrin.h in SSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89021 --- Comment #2 from Richard Biener --- I think that to avoid surprises -mno-mmx should be the default on x86 and thus MMX code would need to explicitely supply -mmmx. Would that work around the issue or would we see odd errors when using the mm intrinsics?
[Bug c++/89024] [7/8/9 Regression] ICE testing convertibility of incomplete enumeration types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89024 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/89027] [9 Regression] ICE: verify_gimple failed (Error: non-trivial conversion at assignment)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89027 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c++/37804] friend declaration leaks into global scope at template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37804 Jonathan Wakely changed: What|Removed |Added Keywords|rejects-valid | Target|x86_64-linux-gnu| Last reconfirmed|2008-10-11 13:07:05 |2019-1-24 Host|x86_64-linux-gnu| Build|x86_64-linux-gnu| --- Comment #9 from Jonathan Wakely --- The cases in comment 6 and comment 8 are a different bug (PR 59930) which was fixed for gcc 8. The original accepts-invalid bug is still present on trunk.
[Bug target/89028] 8-byte loop isn't vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89028
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-* i?86-*-*
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-01-24
Blocks||53947
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Of course we do not vectorize at -O2. At -O3 the issue is the target doesn't
advertise word_mode as vector size to use and the vectorizer doesn't support
vectorization using half of a vector.
If you'd do
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c (revision 268010)
+++ gcc/config/i386/i386.c (working copy)
@@ -50153,6 +50153,11 @@ ix86_autovectorize_vector_sizes (vector_
sizes->safe_push (32);
sizes->safe_push (16);
}
+ else
+{
+ sizes->safe_push (16);
+ sizes->safe_push (8);
+}
}
/* Implemenation of targetm.vectorize.get_mask_mode. */
you get vectorization using DImode regs:
rsqrt:
.LFB0:
.cfi_startproc
movabsq $9187201950435737471, %rdx
movq(%rdi), %rax
movq(%rsi), %rsi
movq%rdx, %rcx
andq%rax, %rcx
andq%rsi, %rdx
xorq%rsi, %rax
addq%rcx, %rdx
movabsq $-9187201950435737472, %rcx
andq%rcx, %rax
xorq%rdx, %rax
movq%rax, (%rdi)
ret
not exactly what you wanted I guess ;) Anything else would require
vectorizer adjustments.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug c++/89029] __builtin_constant_p erroneously true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89029 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Richard Biener --- Yes
[Bug middle-end/89008] [7/8 Regression] O2 and O1 results differ for simple test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89008 --- Comment #8 from Richard Biener --- Author: rguenth Date: Thu Jan 24 09:31:51 2019 New Revision: 268234 URL: https://gcc.gnu.org/viewcvs?rev=268234&root=gcc&view=rev Log: 2019-01-24 Richard Biener Backport from mainline 2019-01-23 Richard Biener PR tree-optimization/89008 * tree-ssa-reassoc.c (eliminate_using_constants): For * 0 do not leave another stray operand. * gcc.dg/torture/pr89008.c: New testcase. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr89008.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-ssa-reassoc.c
[Bug middle-end/89008] [7/8 Regression] O2 and O1 results differ for simple test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89008 --- Comment #9 from Richard Biener --- Bill, you now need r268233 or earlier on the GCC 8 branch to reproduce the latent issue.
[Bug c/89031] Should not report unused result when explicitly cast to void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89031 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Richard Biener --- Indeed (didnt' find resolved invalid dups with the warning in comments though)
[Bug web/89032] Missing documentation for GCC 7.4.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89032 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Richard Biener --- Fixed.
[Bug c++/34724] Trouble with friend declaration across namespaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34724 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Jonathan Wakely --- I think this is another dup of PR 43694 *** This bug has been marked as a duplicate of bug 43694 ***
[Bug c++/43694] G++ accepts a template friend with the wrong template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43694 Jonathan Wakely changed: What|Removed |Added CC||paolo.carlini at oracle dot com --- Comment #3 from Jonathan Wakely --- *** Bug 34724 has been marked as a duplicate of this bug. ***
[Bug c++/65608] [meta-bug] friend issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65608 Bug 65608 depends on bug 34724, which changed state. Bug 34724 Summary: Trouble with friend declaration across namespaces https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34724 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c/89031] Should not report unused result when explicitly cast to void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89031 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #3 from Andrew Pinski --- (In reply to Richard Biener from comment #2) > Indeed (didnt' find resolved invalid dups with the warning in comments > though) Because it was left unconfirmed ... PR 66425. *** This bug has been marked as a duplicate of bug 66425 ***
[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 Andrew Pinski changed: What|Removed |Added CC||porton at narod dot ru --- Comment #37 from Andrew Pinski --- *** Bug 89031 has been marked as a duplicate of this bug. ***
[Bug c++/51584] Erroneous compilation when deriving from an inaccessible friend class.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51584 Jonathan Wakely changed: What|Removed |Added Keywords||accepts-invalid Status|NEW |RESOLVED Last reconfirmed|2015-03-27 00:00:00 |2019-1-24 Blocks|65608 |59002 Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #1) > I think this is related to PR 47346. Yes, it has nothing to do with the friend declaration. *** This bug has been marked as a duplicate of bug 47346 *** Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59002 [Bug 59002] [meta-bug] Access checking in templates https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65608 [Bug 65608] [meta-bug] friend issues
[Bug c++/47346] access control for nested type is ignored in class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47346 Jonathan Wakely changed: What|Removed |Added CC||prasoonsaurav.nit at gmail dot com --- Comment #17 from Jonathan Wakely --- *** Bug 51584 has been marked as a duplicate of this bug. ***
[Bug c++/59002] [meta-bug] Access checking in templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59002 Bug 59002 depends on bug 51584, which changed state. Bug 51584 Summary: Erroneous compilation when deriving from an inaccessible friend class. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51584 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/51757] friend defined inside class and declared inside main linker error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51757
Jonathan Wakely changed:
What|Removed |Added
Keywords||link-failure
Last reconfirmed|2012-01-05 00:00:00 |2019-1-24
--- Comment #5 from Jonathan Wakely ---
Still present on trunk. Clang and EDG emit the definition of func. No version
of GCC I tested (back to 4.3.6) does.
Slightly reduced:
struct A
{
friend void func() { }
};
int main()
{
void func();
func(); //linker error undefined reference to `func()'
}
[Bug c/88993] GCC 9 -Wformat-overflow=2 should reflect real libc limits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88993
--- Comment #6 from Richard W.M. Jones ---
I switched the warning off in libguestfs, but before it was
switched off I got all these warnings (errors in fact because
we use -Werror in development builds).
qemuopts.c: In function 'qemuopts_to_config_channel':
qemuopts.c:987:29: error: '%.*s' directive output between 0 and 2147483647
bytes may exceed minimum required size of 4095 [-Werror=format-overflow=]
987 | fprintf (fp, " %.*s = ", (int) k, values[j]);
| ^~~~
qemuopts.c:987:26: note: assuming directive output of 1 byte
987 | fprintf (fp, " %.*s = ", (int) k, values[j]);
| ^~~
utils.c: In function 'guestfs_int_full_path':
utils.c:729:27: error: '%.*s' directive output between 0 and 2147483647 bytes
may exceed minimum required size of 4095 [-Werror=format-overflow=]
729 | r = asprintf (&path, "%.*s", len, dir);
| ^~~~
utils.c:729:26: note: assuming directive output of 1 byte
729 | r = asprintf (&path, "%.*s", len, dir);
| ^~
utils.c:727:27: error: '%.*s' directive output between 0 and 2147483647 bytes
may exceed minimum required size of 4095 [-Werror=format-overflow=]
727 | r = asprintf (&path, "%.*s/%s", len, dir, name);
| ^~~~
utils.c:727:26: note: assuming directive output of 1 byte
727 | r = asprintf (&path, "%.*s/%s", len, dir, name);
| ^
utils.c:727:26: note: assuming directive output of 1 byte
In file included from info.c:43:
info.c: In function 'parse_json':
info.c:205:13: error: '%.*s' directive output between 0 and 2147483647 bytes
may exceed minimum required size of 4095 [-Werror=format-overflow=]
205 | debug (g, "%s: qemu-img info JSON output:\n%.*s\n", __func__, (int)
len, input);
| ^~~~
guestfs-internal.h:577:49: note: in definition of macro 'debug'
577 | do { if ((g)->verbose) guestfs_int_debug ((g),__VA_ARGS__); } while
(0)
| ^~~
info.c:205:46: note: format string is defined here
205 | debug (g, "%s: qemu-img info JSON output:\n%.*s\n", __func__, (int)
len, input);
| ^~~~
In file included from info.c:43:
info.c:205:13: note: assuming directive output of 1 byte
205 | debug (g, "%s: qemu-img info JSON output:\n%.*s\n", __func__, (int)
len, input);
| ^~~~
guestfs-internal.h:577:49: note: in definition of macro 'debug'
577 | do { if ((g)->verbose) guestfs_int_debug ((g),__VA_ARGS__); } while
(0)
| ^~~
btrfs.c: In function 'do_btrfs_filesystem_show':
btrfs.c:2127:27: error: '%.*s' directive output between 0 and 2147483647 bytes
may exceed minimum required size of 4095 [-Werror=format-overflow=]
2127 | add_sprintf (&ret, "%.*s", (int) (end - p), p);
| ^~~~
btrfs.c:2127:26: note: assuming directive output of 1 byte
2127 | add_sprintf (&ret, "%.*s", (int) (end - p), p);
| ^~
log.c: In function 'do_log':
log.c:390:17: error: '%.*s' directive output between 0 and 2147483647 bytes may
exceed minimum required size of 4095 [-Werror=format-overflow=]
390 | printf (" %.*s", (int) comm_len, comm);
| ^~~~
log.c:390:15: note: assuming directive output of 1 byte
390 | printf (" %.*s", (int) comm_len, comm);
| ^~~
log.c:388:17: error: '%.*s' directive output between 0 and 2147483647 bytes may
exceed minimum required size of 4095 [-Werror=format-overflow=]
388 | printf (" %.*s", (int) identifier_len, identifier);
| ^~~~
log.c:388:15: note: assuming directive output of 1 byte
388 | printf (" %.*s", (int) identifier_len, identifier);
| ^~~
log.c:394:17: error: '%.*s' directive output between 0 and 2147483647 bytes may
exceed minimum required size of 4095 [-Werror=format-overflow=]
394 | printf ("[%.*s]", (int) pid_len, pid);
| ^~~~
log.c:394:15: note: assuming directive output of 1 byte
394 | printf ("[%.*s]", (int) pid_len, pid);
| ^~~~
log.c:404:17: error: '%.*s' directive output between 0 and 2147483647 bytes may
exceed minimum required size of 4095 [-Werror=format-overflow=]
404 | printf (" %.*s", (int) message_len, message);
| ^~~~
log.c:404:15: note: assuming directive output of 1 byte
404 | printf (" %.*s", (int) message_len, message);
| ^~~
../common/utils/utils.c: In function 'guestfs_int_full_path':
../common/utils/utils.c:729:27: error: '%.*s' directive output betw
[Bug c++/52625] [7/8/9 Regression] Incorrect specialization semantics of friend class template declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52625 Jonathan Wakely changed: What|Removed |Added Last reconfirmed|2012-03-20 00:00:00 |2019-1-24 CC||jason at gcc dot gnu.org Known to work||4.4.7 Summary|Incorrect specialization|[7/8/9 Regression] |semantics of friend class |Incorrect specialization |template declaration|semantics of friend class ||template declaration Known to fail||4.5.4, 7.4.0, 8.2.0, 9.0 --- Comment #4 from Jonathan Wakely --- This was accepted by 4.4.7 but not 4.5.0 It regressed with r154223 "PR c++/13950, DR 176" (which was indeed related to finding the injected-class-name in a base class).
[Bug tree-optimization/89027] [9 Regression] ICE: verify_gimple failed (Error: non-trivial conversion at assignment)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89027 --- Comment #3 from Jakub Jelinek --- Created attachment 45517 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45517&action=edit gcc9-pr89027.patch Untested fix.
[Bug libfortran/89020] close(status='DELETE') does not remove file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-01-24 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- > If virtualbox's shared folders are doing strange things with > files or is broken, not much that the gfortran developers > can do about that. Hence closing as WONTFIX?
[Bug c++/89001] g++ uses wrong mangling for lifetime-extended temporaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89001 --- Comment #3 from Jakub Jelinek --- So do we need a GTY hash table mapping VAR_DECLs to lifetime-extended temporary count and use that during the mangling?
[Bug lto/87187] FAIL: gfortran.dg/short_circuiting_3.f90 -g -flto (internal compiler error) on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87187
Richard Biener changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #6 from Richard Biener ---
OK, so we end up here via force_decl_die which forces declaration == 1. But
then
/* A concrete instance, tag a new DIE with DW_AT_abstract_origin. */
if (origin != NULL)
{
gcc_assert (!declaration || local_scope_p (context_die));
where origin == decl because decl_ultimate_origin returns decl itself
since its DECL_ABSTRACT_ORIGIN points to itself but it is not DECL_ABSTRACT_P.
In the end we force the decl as context for a limbo DIE for a local static
in the function ('i').
We're still doing that set_decl_origin_self on stuff via
dwarf2out_abstract_function (tried to get rid of that repeatedly...).
We're fooling dwarf2out here that an abstract origin DIE exists but with
the LTO workaround it doesn't.
On Linux if we compile with -g0 the DECL_ABSTRACT_ORIGIN will not be set
while on Darwin compiling with -g will just elide the LTO part but still
set DECL_ABSTRACT_ORIGIN. We cannot simply not stream DECL_ABSTRACT_ORIGIN
if debug_info_level == DINFO_LEVEL_NONE because IIRC it is used for other
stuff as well(?). Maybe just eliding the self-origin case works.
So I am testing
Index: gcc/tree-streamer-out.c
===
--- gcc/tree-streamer-out.c (revision 268233)
+++ gcc/tree-streamer-out.c (working copy)
@@ -603,7 +603,16 @@ write_ts_decl_common_tree_pointers (stru
special handling in LTO, it must be handled by streamer hooks. */
stream_write_tree (ob, DECL_ATTRIBUTES (expr), ref_p);
- stream_write_tree (ob, DECL_ABSTRACT_ORIGIN (expr), ref_p);
+
+ /* On non-early-LTO enabled targets we claim we compiled with -g0
+ but dwarf2out still did its set_decl_origin_self game fooling
+ itself late. Und that here since we won't have access to the
+ early generated abstract DIEs. */
+ tree ao = DECL_ABSTRACT_ORIGIN (expr);
+ if (debug_info_level == DINFO_LEVEL_NONE
+ && ao == expr)
+ao = NULL_TREE;
+ stream_write_tree (ob, ao, ref_p);
if ((VAR_P (expr) || TREE_CODE (expr) == PARM_DECL)
&& DECL_HAS_VALUE_EXPR_P (expr))
which fixes the testcase at least.
[Bug libstdc++/89023] libstdc++ test failure; can't find omp.h with --disable-libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89023
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-01-24
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
(In reply to sandra from comment #0)
> Is there some reason this test is conditionalized differently than, say,
> 28_regex/headers/regex/parallel_mode.cc ?? That one is properly recognized
> as unsupported on this target.
That's the same header :-)
I think it should probably be the same as
25_algorithms/headers/algorithm/algorithm_parallel_mode.cc i.e.
// { dg-require-parallel-mode "" }
// { dg-options "-D_GLIBCXX_PARALLEL -fopenmp" { target *-*-* } }
(Although that will mean it almost never gets tested, as nobody runs make
check-parallel routinely ... not that it really matters, as nobody uses
parallel mode either, and it will be deprecated soon).
> Also, the underlying failure seems related to pr35887. Why is libstdc++
> even installing headers that depend on omp.h with --disable-libgomp?
Probably because it was easier that way. They only depend on omp.h if you
explicitly request it by defining _GLIBCXX_PARALLEL, and if you do that without
libgomp that's your fault. The test that does that needs to be fixed.
[Bug c++/89025] Wrong point of declaration for enumeration names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89025 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-24 Ever confirmed|0 |1
[Bug c++/89029] __builtin_constant_p erroneously true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89029 --- Comment #3 from Jonathan Wakely --- (In reply to Peter Dimov from comment #0) > (This is simplified from an attempt to create a statically-diagnosed assert > facility that would warn when the asserted expression is known to be false: > https://godbolt.org/z/i5SXSd. Would've been cool if it worked.) c.f. https://gcc.gnu.org/ml/libstdc++/2018-03/msg00031.html and the replies
[Bug web/89032] Missing documentation for GCC 7.4.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89032 Martin Liška changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2019-01-24 Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Please add missing CSS file for it, take a look here: https://gcc.gnu.org/onlinedocs/7.3.0/
[Bug tree-optimization/87214] [9 Regression] r263772 miscompiled 520.omnetpp_r in SPEC CPU 2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87214 Martin Liška changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|INVALID |--- Assignee|rsandifo at gcc dot gnu.org|marxin at gcc dot gnu.org --- Comment #6 from Martin Liška --- Well, omnetpp_r has no known portability issues: https://www.spec.org/cpu2017/Docs/benchmarks/520.omnetpp_r.html So that I would like to know what violates the aliasing. Let me debug that..
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 87214, which changed state. Bug 87214 Summary: [9 Regression] r263772 miscompiled 520.omnetpp_r in SPEC CPU 2017 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87214 What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|INVALID |---
[Bug fortran/89033] New: gfortran accepts invalid code in select type construct with pointer assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89033 Bug ID: 89033 Summary: gfortran accepts invalid code in select type construct with pointer assignment Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mscfd at gmx dot net Target Milestone: --- The code below should be invalid, as the selector x has attribute "target" but not "pointer" inside the select type block (2008 draft, 8.1.3.3). The code compiles, but it gives a suprising output, namely x is still associated, despite the accepted "x => null()" line. program select_type_ptr implicit none type t integer :: i = 1 end type t class(*), pointer :: x type(t), pointer :: y allocate(x, source = t(3)) select type (x) type is (t) y => x x => null() end select print *, associated(x), associated(y) print *, y%i end program select_type_ptr
[Bug c++/56643] Failure to match noexcept specifier of friend template function in template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56643 Jonathan Wakely changed: What|Removed |Added Keywords||ice-on-valid-code, ||rejects-valid Last reconfirmed|2013-03-17 00:00:00 |2019-1-24 --- Comment #3 from Jonathan Wakely --- This was rejects-valid in GCC 4.9 but since GCC 5 is ice-on-valid-code
[Bug tree-optimization/87214] [9 Regression] r263772 miscompiled 520.omnetpp_r in SPEC CPU 2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87214 --- Comment #7 from rguenther at suse dot de --- On Thu, 24 Jan 2019, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87214 > > Martin Liška changed: > >What|Removed |Added > > Status|RESOLVED|ASSIGNED > Resolution|INVALID |--- >Assignee|rsandifo at gcc dot gnu.org|marxin at gcc dot > gnu.org > > --- Comment #6 from Martin Liška --- > Well, omnetpp_r has no known portability issues: > https://www.spec.org/cpu2017/Docs/benchmarks/520.omnetpp_r.html > > So that I would like to know what violates the aliasing. Let me debug that.. A lot of benchmarks end up using spec_qsort...
[Bug c++/65608] [meta-bug] friend issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65608 Bug 65608 depends on bug 56820, which changed state. Bug 56820 Summary: elaborated-type-specifier friend incorrectly looked up beyond innermost enclosing namespace https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56820 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/59930] template friend declarations, namespaces, and explicit instantiations don't mix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59930 Jonathan Wakely changed: What|Removed |Added CC||wd11 at leicester dot ac.uk --- Comment #9 from Jonathan Wakely --- *** Bug 56820 has been marked as a duplicate of this bug. ***
[Bug c++/56820] elaborated-type-specifier friend incorrectly looked up beyond innermost enclosing namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56820 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jonathan Wakely --- Fixed by Nathan's patch for PR 59930, and looks like a dup of it. *** This bug has been marked as a duplicate of bug 59930 ***
[Bug c++/21146] unable to resolve visible symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21146
--- Comment #6 from Jonathan Wakely ---
EDG still accepts this, but Clang doesn't:
21146.cc:13:18: error: member 'S' found in multiple base classes of different
types
friend class A;
^
21146.cc:7:8: note: member found by ambiguous name lookup
struct S {};
^
21146.cc:4:13: note: member found by ambiguous name lookup
typedef T S;
^
21146.cc:13:18: error: member 'S' found in multiple base classes of different
types
friend class A;
^
21146.cc:7:8: note: member found by ambiguous name lookup
struct S {};
^
21146.cc:4:13: note: member found by ambiguous name lookup
typedef T S;
^
2 errors generated.
I think GCC and Clang are right here.
[Bug tree-optimization/87214] [9 Regression] r263772 miscompiled 520.omnetpp_r in SPEC CPU 2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87214 --- Comment #8 from Martin Liška --- (In reply to rguent...@suse.de from comment #7) > On Thu, 24 Jan 2019, marxin at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87214 > > > > Martin Liška changed: > > > >What|Removed |Added > > > > Status|RESOLVED|ASSIGNED > > Resolution|INVALID |--- > >Assignee|rsandifo at gcc dot gnu.org|marxin at gcc dot > > gnu.org > > > > --- Comment #6 from Martin Liška --- > > Well, omnetpp_r has no known portability issues: > > https://www.spec.org/cpu2017/Docs/benchmarks/520.omnetpp_r.html > > > > So that I would like to know what violates the aliasing. Let me debug that.. > > A lot of benchmarks end up using spec_qsort... Ah, yes, I overlooked that as the file has a different suffix: ./benchspec/CPU/520.omnetpp_r/src/simulator/spec_qsort.cc So let me test it with fixed qsort function.
[Bug middle-end/89008] [7/8 Regression] O2 and O1 results differ for simple test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89008 Richard Biener changed: What|Removed |Added Known to work||7.4.1, 8.2.1 --- Comment #11 from Richard Biener --- "fixed" everywhere, I'm out of the way now, SLSR is still latently buggy (I suggest to simply "ignore" * 0 stmts)
[Bug middle-end/89008] [7/8 Regression] O2 and O1 results differ for simple test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89008 --- Comment #10 from Richard Biener --- Author: rguenth Date: Thu Jan 24 11:07:19 2019 New Revision: 268235 URL: https://gcc.gnu.org/viewcvs?rev=268235&root=gcc&view=rev Log: 2019-01-24 Richard Biener Backport from mainline 2019-01-23 Richard Biener PR tree-optimization/89008 * tree-ssa-reassoc.c (eliminate_using_constants): For * 0 do not leave another stray operand. * gcc.dg/torture/pr89008.c: New testcase. Added: branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr89008.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/tree-ssa-reassoc.c
[Bug testsuite/89034] New: [libgomp, openacc] dg-shouldfail in abort-1.c allows libgomp asserts to go undetected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89034
Bug ID: 89034
Summary: [libgomp, openacc] dg-shouldfail in abort-1.c allows
libgomp asserts to go undetected
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
See "[nvptx, openacc, libgomp] Assertion `!s->map->active' failed for
synchronous parallel with abort" ( PR88939 ).
A commit triggered an assert in abort-1.c, but because of dg-shouldfail, the
test-case continued passing. Eventually, it was noticed by manual inspection
of libgomp.log, months after the offending commit was committed to trunk,
instead of during pre-commit testing, which would have been preferable.
If a dg-output-not directive was available, we could improve the abort-1.c
testcase somewhat by adding:
...
/* { dg-output-not "Assertion.*failed" } */
...
or some such.
[Bug testsuite/89034] [libgomp, openacc] dg-shouldfail in abort-1.c allows libgomp asserts to go undetected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89034
Tom de Vries changed:
What|Removed |Added
Keywords||openacc
CC||tschwinge at gcc dot gnu.org
Severity|normal |enhancement
--- Comment #1 from Tom de Vries ---
This is a rewrite of abort-1.c that gets rid of the dg-shouldfail, by using
on_exit:
...
/* { dg-do run { target { ! openacc_host_selected } } } */
#include
#include
#include
static int trace;
static void
exit_handler (int status, void *arg)
{
if (trace != 1)
abort ();
if (status != EXIT_FAILURE)
abort ();
_exit (0);
}
int
main (void)
{
trace = 0;
on_exit (exit_handler, NULL);
trace++;
#pragma acc parallel
{
abort ();
}
trace++;
return 0;
}
/* { dg-output "libgomp: " } */
...
[Bug testsuite/89034] [libgomp, openacc] dg-shouldfail in abort-1.c allows libgomp asserts to go undetected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89034 --- Comment #2 from Tom de Vries --- Thomas, is this replacement for abort-1.c OK for trunk? If so, I'll commit this, otherwise, I'll commit this as abort-nvptx.c or some such. Thanks - Tom
[Bug debug/89006] [9 Regression] New note: non-delegitimized UNSPEC UNSPEC_SET_GOT (14) found in variable location since r267638
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89006 --- Comment #1 from Jakub Jelinek --- Created attachment 45518 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45518&action=edit gcc9-pr89006.patch Untested fix.
[Bug c++/89029] __builtin_constant_p erroneously true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89029
--- Comment #4 from Peter Dimov ---
(In reply to Jonathan Wakely from comment #3)
> c.f. https://gcc.gnu.org/ml/libstdc++/2018-03/msg00031.html and the replies
Yes, pretty much.
> I doubt we would catch many bugs that way, as most bugs would involve
> non-constant indices and vectors that have changed size dynamically at
> run-time.
It's still pretty cool when it works, f.ex. here: https://godbolt.org/z/fHCB16
Annoying that we're so close to useful static analysis but it doesn't _quite_
work. (Also note how the code for g() goes straight to assert without telling
anyone.)
>RESOLVED INVALID
Too bad. FWIW, Clang trunk doesn't seem to suffer from the false positive
problem. It also "proves" the assertion failure in g, but not in f:
https://godbolt.org/z/92WyvR. (It also doesn't support __attribute((error)),
which makes this technique limited in value.)
Maybe the correct way to go about this is just to mark __assert_fail in some
manner ("warn if unconditionally called"), instead of trying to (ab)use
__builtin_constant_p.
[Bug tree-optimization/87214] [9 Regression] r263772 miscompiled 520.omnetpp_r in SPEC CPU 2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87214
--- Comment #9 from Martin Liška ---
I guess it's not related to qsort (the files looks different and fine:
#include
#include "spec_qsort.h"
static void spec_swap(void *x, void *y, size_t l) {
/* Swap elements of an array byte by byte. Note that a version specialized
to
operate on a specific data type (e.g. int) would be faster. */
char *a = (char *)x, *b = (char *)y, c;
while(l--) {
c = *a;
*a++ = *b;
*b++ = c;
}
}
static void spec_sort(char *array, size_t size, int begin, int end, int
(*cmp)(const void*,const void*)) {
/* Generic qsort algorithm */
if (end > begin) {
void *pivot = array + begin;
int l = begin + size;
int r = end;
while(l < r) {
if (cmp(array+l,pivot) <= 0) {
l += size;
} else {
r -= size;
spec_swap(array+l, array+r, size);
}
}
l -= size;
spec_swap(array+begin, array+l, size);
spec_sort(array, size, begin, l, cmp);
spec_sort(array, size, r, end, cmp);
}
}
void spec_qsort(void *array, size_t nitems, size_t size, int (*cmp)(const
void*,const void*)) {
spec_sort((char *)array, size, 0, (nitems-1)*size, cmp);
}
[Bug tree-optimization/87214] [9 Regression] r263772 miscompiled 520.omnetpp_r in SPEC CPU 2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87214 --- Comment #10 from Martin Liška --- Only following 2 LTO object files trigger the segfault: simulator/cpar.o and simulator/ccomponent.o (rest are -fno-lto object files).
[Bug c++/59930] template friend declarations, namespaces, and explicit instantiations don't mix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59930 Jonathan Wakely changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #10 from Jonathan Wakely --- *** Bug 59815 has been marked as a duplicate of this bug. ***
[Bug c++/59815] Apparently bogus error: 'Outer' is already declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59815 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #2) > I think this is a duplicate of bug 37804. It's a dup of bug 37804 comment 6 which is actually PR 59930, and fixed. *** This bug has been marked as a duplicate of bug 59930 ***
[Bug c++/65608] [meta-bug] friend issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65608 Bug 65608 depends on bug 59815, which changed state. Bug 59815 Summary: Apparently bogus error: 'Outer' is already declared in this scope https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59815 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/57376] Bogus error due to failure of unqualified namespace lookup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57376 Jonathan Wakely changed: What|Removed |Added CC||nicolas.bertolotti@mathwork ||s.fr --- Comment #1 from Jonathan Wakely --- *** Bug 60611 has been marked as a duplicate of this bug. ***
[Bug c++/65608] [meta-bug] friend issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65608 Bug 65608 depends on bug 60611, which changed state. Bug 60611 Summary: friend function declaration rejected when the namespace in which it is declared is not explicitely specified in the declaration https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60611 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/60611] friend function declaration rejected when the namespace in which it is declared is not explicitely specified in the declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60611 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- This looks like a dup *** This bug has been marked as a duplicate of bug 57376 ***
[Bug c++/61327] Problem with friend template object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61327 --- Comment #3 from Jonathan Wakely --- Fixed for GCC 6 by r227023, which fixed PR 66957. The examples here look different enough that we should probably add them to the testsuite before closing this.
[Bug c++/65619] friend declaration with template template parameter not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65619 --- Comment #1 from Jonathan Wakely --- Fixed for GCC 6 by r227023, which fixed PR 66957. The example here looks different enough that we should probably add it to the testsuite before closing this.
[Bug target/87064] [9 regression] libgomp.oacc-fortran/reduction-3.f90 fails starting with r263751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #25 from Jakub Jelinek --- Testcase fixed, *vsx_reduc__v4sf_scalar hasn't been disabled for little endian (is it incorrect too or just non-optimal)?
[Bug libstdc++/88999] [9 Regression] testcases using in_avail() fail on nios2-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88999 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug tree-optimization/88760] GCC unrolling is suboptimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #17 from ktkachov at gcc dot gnu.org ---
I played around with the source to do some conservative 2x manual unrolling in
the two hottest functions in 510.parest_r (3 more-or-less identical tight FMA
loops). This was to try out Richard's thinking suggestion in #c10 about
unrolling for forming load-pairs, and also to break the accumulator dependency.
So the initial testcase now became:
unsigned int *colnums;
double *val;
struct foostruct
{
unsigned int rows;
unsigned int *colnums;
unsigned int *rowstart;
};
struct foostruct *cols;
void
foo (double * __restrict__ dst, const double *__restrict__ src)
{
const unsigned int n_rows = cols->rows;
const double *val_ptr = &val[cols->rowstart[0]];
const unsigned int *colnum_ptr = &cols->colnums[cols->rowstart[0]];
double *dst_ptr = dst;
for (unsigned int row=0; rowrowstart[row+1]];
__PTRDIFF_TYPE__ diff = val_end_of_row - val_ptr;
if (diff & 1) // Peel the odd iteration.
s += *val_ptr++ * src[*colnum_ptr++];
double s1 = 0.; // Second accumulator
while (val_ptr != val_end_of_row)
{
s += val_ptr[0] * src[colnum_ptr[0]];
s1 += val_ptr[1] * src[colnum_ptr[1]];
val_ptr += 2;
colnum_ptr += 2;
}
*dst_ptr++ = s + s1;
}
}
This transformed the initial loop from:
.L4:
ldr w3, [x7, x2, lsl 2]
cmp x6, x2
ldr d2, [x5, x2, lsl 3]
add x2, x2, 1
ldr d1, [x1, x3, lsl 3]
fmadd d0, d2, d1, d0
bne .L4
into:
.L5:
ldp w6, w5, [x3] // LDP
add x3, x3, 8
ldp d5, d3, [x2] // LDP
add x2, x2, 16
ldr d4, [x1, x6, lsl 3]
cmp x4, x2
ldr d2, [x1, x5, lsl 3]
fmadd d0, d5, d4, d0
fmadd d1, d3, d2, d1
bne .L5
In parest itself a few of the loops transformed this way did not form LDPs due
to unrelated LDP-forming inefficiencies but the most did.
This transformation gave a 3% improvement on a Cortex-A72. There are more
similar loops in the 3rd, 4th and 5th hottest functions in that benchmark, so I
suspect if we do something intelligent there as well we'll get even more
sizeable gains.
So rather than solving general "unrolling", how about we break this down into
two desirable transformations:
1) Unrolling for load-pair-forming vectorisation (Richard Sandiford's
suggestion)
2) Unrolling and breaking accumulator dependencies.
I think more general unrolling and the peeling associated with it can be
discussed independently of 1) and 2) once we collect more data on more
microarchitectures.
[Bug c/89035] New: Request - builtins for unspecified and arbitrary values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89035
Bug ID: 89035
Summary: Request - builtins for unspecified and arbitrary
values
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
Occasionally it is useful to have an unspecified or arbitrary value in C (and
C++) programming. For example, you might want to have a function that
calculates a particular value for valid inputs, and returns an unspecified
value on invalid inputs.
At the moment, gcc has __builtin_unreachable() to indicate intentional manually
created undefined behaviour - it is useful for getting optimal code, and also
for documenting code. And it provides a reliable way of saying "this can't
happen", unlike other undefined behaviour (such as writing "1/0;").
Unspecified and arbitrary values are different from undefined values - the
compiler is free to pick them in any way it likes, but the values are valid and
non-trapping, and operations using them are defined behaviour, though with
possibly unspecified or arbitrary results.
An unspecified value can be created by making a local variable and leaving it
uninitialised - but that will usually be flagged by a warning from gcc, and it
is not clear in the code. An arbitrary value can be generated by inline
assembly, such as " int x; asm("" : "=r" (x)); " which generates no code.
However, that does not give the compiler freedom to pick a different arbitrary
value of its liking.
I would like to suggest there be builtin functions __builtin_unspecified() and
__builtin_arbitrary(). They would both return an "int" - I don't think there
is need for any other types.
The difference between this can be seen with code like this:
int x = __builtin_arbitrary();
int y = x - x;// y is guaranteed to be 0.
int x = __builtin_unspecified();
int y = x - x;// y is unspecified.
An initial implementation could be very simple.
__builtin_unspecified() can use the existing unspecified value logic in the
compiler, or could be viewed as __builtin_arbitrary().
__builtin_arbitrary() can work like the inline assembly shown above, or just
return 0.
Of course, a better implementation would allow more optimisations - the
compiler could pick different values that result in more efficient code later.
[Bug tree-optimization/88760] GCC unrolling is suboptimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #18 from rguenther at suse dot de ---
On Thu, 24 Jan 2019, ktkachov at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
>
> --- Comment #17 from ktkachov at gcc dot gnu.org ---
> I played around with the source to do some conservative 2x manual unrolling in
> the two hottest functions in 510.parest_r (3 more-or-less identical tight FMA
> loops). This was to try out Richard's thinking suggestion in #c10 about
> unrolling for forming load-pairs, and also to break the accumulator
> dependency.
>
> So the initial testcase now became:
> unsigned int *colnums;
> double *val;
>
> struct foostruct
> {
> unsigned int rows;
> unsigned int *colnums;
> unsigned int *rowstart;
> };
>
> struct foostruct *cols;
>
> void
> foo (double * __restrict__ dst, const double *__restrict__ src)
> {
> const unsigned int n_rows = cols->rows;
> const double *val_ptr = &val[cols->rowstart[0]];
> const unsigned int *colnum_ptr = &cols->colnums[cols->rowstart[0]];
>
> double *dst_ptr = dst;
> for (unsigned int row=0; row {
> double s = 0.;
> const double *const val_end_of_row = &val[cols->rowstart[row+1]];
> __PTRDIFF_TYPE__ diff = val_end_of_row - val_ptr;
>
> if (diff & 1) // Peel the odd iteration.
> s += *val_ptr++ * src[*colnum_ptr++];
>
> double s1 = 0.; // Second accumulator
> while (val_ptr != val_end_of_row)
> {
> s += val_ptr[0] * src[colnum_ptr[0]];
> s1 += val_ptr[1] * src[colnum_ptr[1]];
> val_ptr += 2;
> colnum_ptr += 2;
> }
> *dst_ptr++ = s + s1;
> }
> }
>
> This transformed the initial loop from:
> .L4:
> ldr w3, [x7, x2, lsl 2]
> cmp x6, x2
> ldr d2, [x5, x2, lsl 3]
> add x2, x2, 1
> ldr d1, [x1, x3, lsl 3]
> fmadd d0, d2, d1, d0
> bne .L4
>
> into:
> .L5:
> ldp w6, w5, [x3] // LDP
> add x3, x3, 8
> ldp d5, d3, [x2] // LDP
> add x2, x2, 16
> ldr d4, [x1, x6, lsl 3]
> cmp x4, x2
> ldr d2, [x1, x5, lsl 3]
> fmadd d0, d5, d4, d0
> fmadd d1, d3, d2, d1
> bne .L5
>
> In parest itself a few of the loops transformed this way did not form LDPs due
> to unrelated LDP-forming inefficiencies but the most did.
> This transformation gave a 3% improvement on a Cortex-A72. There are more
> similar loops in the 3rd, 4th and 5th hottest functions in that benchmark, so
> I
> suspect if we do something intelligent there as well we'll get even more
> sizeable gains.
>
> So rather than solving general "unrolling", how about we break this down into
> two desirable transformations:
> 1) Unrolling for load-pair-forming vectorisation (Richard Sandiford's
> suggestion)
If that helps, sure (I'd have guessed uarchs are going to split
load-multiple into separate loads, but eventually it avoids
load-port contention?)
> 2) Unrolling and breaking accumulator dependencies.
IIRC RTL unrolling can do this (as side-effect, not as main
cost motivation) guarded with an extra switch.
> I think more general unrolling and the peeling associated with it can be
> discussed independently of 1) and 2) once we collect more data on more
> microarchitectures.
I think both of these can be "implemented" on the RTL unroller
side.
[Bug lto/87187] FAIL: gfortran.dg/short_circuiting_3.f90 -g -flto (internal compiler error) on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87187 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener --- Fixed on trunk, not sure if it is a regression also present on the branch?
[Bug debug/86549] [8/9 Regression] -flto -g0 vs. -g issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86549 Bug 86549 depends on bug 87187, which changed state. Bug 87187 Summary: FAIL: gfortran.dg/short_circuiting_3.f90 -g -flto (internal compiler error) on darwin https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87187 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug lto/87187] FAIL: gfortran.dg/short_circuiting_3.f90 -g -flto (internal compiler error) on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87187 --- Comment #8 from Richard Biener --- Author: rguenth Date: Thu Jan 24 12:36:14 2019 New Revision: 268236 URL: https://gcc.gnu.org/viewcvs?rev=268236&root=gcc&view=rev Log: 2019-01-24 Richard Biener PR lto/87187 * tree-streamer-out.c (write_ts_decl_common_tree_pointers): When in "legacy" debug mode make sure to reset self-origins. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-streamer-out.c
[Bug target/89021] Implement mmintrin.h in SSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89021 --- Comment #3 from H.J. Lu --- (In reply to Uroš Bizjak from comment #1) > Porbably we just need to add SSE alternatives to existing MMX builtins. C.f. > [1]. > > [1] https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01393.html Yes, and a few other improvements.
[Bug target/89021] Implement mmintrin.h in SSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89021
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-01-24
Ever confirmed|0 |1
--- Comment #4 from H.J. Lu ---
(In reply to Richard Biener from comment #2)
> I think that to avoid surprises -mno-mmx should be the default on x86 and
> thus
> MMX code would need to explicitely supply -mmmx. Would that work around the
> issue or would we see odd errors when using the mm intrinsics?
That sounds right. We can even vectorize
void
foo (char* restrict r, char* restrict a){
for (int i = 0; i < 8; i++){
r[i] += a[i];
}
}
[Bug c/89035] Request - builtins for unspecified and arbitrary values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89035 --- Comment #1 from Marc Glisse --- We already have int x = x; for one of those, no? Or just int x; but it tends to warn.
[Bug c/89035] Request - builtins for unspecified and arbitrary values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89035 --- Comment #2 from David Brown --- Yes, "int x = x;" does give an unspecified value without a warning. But to me, this looks much more like a workaround - while "int x = __builtin_unspecified();" is clear in its intentions.
[Bug c++/88969] [9 Regression] ICE in build_op_delete_call, at cp/call.c:6509
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88969 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #5 from Paolo Carlini --- Mine.
[Bug tree-optimization/88760] GCC unrolling is suboptimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760 --- Comment #19 from Wilco --- (In reply to rguent...@suse.de from comment #18) > > 1) Unrolling for load-pair-forming vectorisation (Richard Sandiford's > > suggestion) > > If that helps, sure (I'd have guessed uarchs are going to split > load-multiple into separate loads, but eventually it avoids > load-port contention?) Many CPUs execute LDP/STP as a single load/store, eg. Cortex-A57 executes a 128-bit LDP in a single cycle (see Optimization Guide). > > 2) Unrolling and breaking accumulator dependencies. > > IIRC RTL unrolling can do this (as side-effect, not as main > cost motivation) guarded with an extra switch. > > > I think more general unrolling and the peeling associated with it can be > > discussed independently of 1) and 2) once we collect more data on more > > microarchitectures. > > I think both of these can be "implemented" on the RTL unroller > side. You still need dependence analysis, alias info, ivopt to run again. The goal is to remove the increment of the index, use efficient addressing modes (base+imm) and allow scheduling to move instructions between iterations. I don't believe the RTL unroller supports any of this today.
[Bug preprocessor/88974] [9 Regression] ICE: Segmentation fault (in linemap_resolve_location)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88974 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-01-24 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 45519 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45519&action=edit gcc9-pr88974.patch Untested fix. That said, I see no signs why this is a regression.
[Bug libfortran/89020] close(status='DELETE') does not remove file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020 --- Comment #3 from Thomas Koenig --- (In reply to Dominique d'Humieres from comment #2) > > If virtualbox's shared folders are doing strange things with > > files or is broken, not much that the gfortran developers > > can do about that. > > Hence closing as WONTFIX? First, what virtualbox is doing is a violation of common UNIX semantics, so we would be within our rights :-) to do this. However, I'd like to look at the code first and check if we can actually accommodate this strange behavior without pessimizing anything else. If so, I would be inclined to "fix" this. On the third hand, I seem to remember that unlink / close also used to cause (potential?) issues with NFS.
[Bug c++/88951] [9 Regression] No fpermissive offerred on 'error: jump to case label'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88951 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Your testcase doesn't compile anywhere, you need to add at least a semicolon after case 0: With that fixed, whether this was accepted or not changed over time several times, e.g. 3.2 accepted it with warnings (and -fpermissive in all cases), 3.3 - 4.9 emitted a warning and error, 5.x-8.x gave just a warning or two, 9.x error + warning. I'd say just fix the legacy code.
[Bug tree-optimization/88760] GCC unrolling is suboptimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760 --- Comment #20 from rguenther at suse dot de --- On Thu, 24 Jan 2019, wilco at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760 > > --- Comment #19 from Wilco --- > (In reply to rguent...@suse.de from comment #18) > > > > 1) Unrolling for load-pair-forming vectorisation (Richard Sandiford's > > > suggestion) > > > > If that helps, sure (I'd have guessed uarchs are going to split > > load-multiple into separate loads, but eventually it avoids > > load-port contention?) > > Many CPUs execute LDP/STP as a single load/store, eg. Cortex-A57 executes a > 128-bit LDP in a single cycle (see Optimization Guide). > > > > 2) Unrolling and breaking accumulator dependencies. > > > > IIRC RTL unrolling can do this (as side-effect, not as main > > cost motivation) guarded with an extra switch. > > > > > I think more general unrolling and the peeling associated with it can be > > > discussed independently of 1) and 2) once we collect more data on more > > > microarchitectures. > > > > I think both of these can be "implemented" on the RTL unroller > > side. > > You still need dependence analysis, alias info, ivopt to run again. The goal > is > to remove the increment of the index, use efficient addressing modes > (base+imm) > and allow scheduling to move instructions between iterations. I don't believe > the RTL unroller supports any of this today. There's no way to encode load-multiple on GIMPLE that wouldn't be awkward to other GIMPLE optimizers. Yes, the RTL unroller supports scheduling (sched runs after unrolling) and scheduling can do dependence analysis. Yes, the RTL unroller does _not_ do dependence analysis at the moment, so if you want to know beforehand whether you can interleave iterations you have to actually perform dependence analysis. Of course you can do that on RTL. And of course you can do IVOPTs on RTL (yes, we don't do that at the moment). Note I'm not opposed to have IVOPTs on GIMPLE itself perform unrolling (I know Bin was against this given IVOPTs is already so comples) and a do accumulator breakup. But I don't see how to do the load-multiple thing (yes, you could represent it as a vector load plus N element extracts on GIMPLE and it would be easy to teach SLP vectorization to perform this transform on its own if it is really profitable - which I doubt you can reasonably argue before RA, let alone on GIMPLE).
[Bug c++/88988] [8/9 Regression] ICE: Segmentation fault (in lookup_name_real_1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88988 Jakub Jelinek changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- This is not valid, if you firstprivatize a nonstatic data member, accessing it through this is undefined behavior.
[Bug middle-end/89008] [7/8 Regression] O2 and O1 results differ for simple test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89008 --- Comment #12 from Bill Schmidt --- Yes, fully agree -- I'll take care of that probably tomorrow. Too many meetings this week...
[Bug c++/89036] ICE if destructor has a requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89036 --- Comment #1 from Antony Polukhin --- Compile with flags: -std=c++2a -fconcepts
[Bug tree-optimization/87214] [9 Regression] r263772 miscompiled 520.omnetpp_r in SPEC CPU 2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87214 --- Comment #12 from Martin Liška --- Created attachment 45521 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45521&action=edit optimized dump with -mprefer-vector-width=256
[Bug c++/89036] New: ICE if destructor has a requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89036
Bug ID: 89036
Summary: ICE if destructor has a requires
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
The following code:
template
struct Y {
~Y() requires(true) = default;
~Y() requires(false) {}
};
causes ICE:
:6:27: internal compiler error: in add_method, at cp/class.c:1137
6 | ~Y() requires(false) {}
| ^
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug middle-end/89037] New: checking ice emitting 128-bit bit-field initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89037
Bug ID: 89037
Summary: checking ice emitting 128-bit bit-field initializer
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-checking, ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
/* ./cc1 testcase.c */
struct s
{
__int128 y : 65;
};
typedef struct s T;
T a = { 1 };
Results in
besttry.c:7:1: internal compiler error: tree check: accessed elt 2 of
tree_int_cst with 1 elts in output_constructor_bitfield, at varasm.c:5410
7 | T a = { 1 };
| ^
0x5be4f1 tree_int_cst_elt_check_failed(int, int, char const*, int, char const*)
/home/rearnsha/gnusrc/gcc-cross/trunk/gcc/tree.c:
0x740049 tree_int_cst_elt_check(tree_node*, int, char const*, int, char const*)
/home/rearnsha/gnusrc/gcc-cross/trunk/gcc/tree.h:3378
0xf8d530 output_constructor_bitfield
/home/rearnsha/gnusrc/gcc-cross/trunk/gcc/varasm.c:5410
0xf8db12 output_constructor
/home/rearnsha/gnusrc/gcc-cross/trunk/gcc/varasm.c:5524
0xf8c27f output_constant
/home/rearnsha/gnusrc/gcc-cross/trunk/gcc/varasm.c:5037
0xf81a96 assemble_variable_contents
/home/rearnsha/gnusrc/gcc-cross/trunk/gcc/varasm.c:2144
0xf82519 assemble_variable(tree_node*, int, int, int)
/home/rearnsha/gnusrc/gcc-cross/trunk/gcc/varasm.c:2323
0xfa03c4 varpool_node::assemble_decl()
/home/rearnsha/gnusrc/gcc-cross/trunk/gcc/varpool.c:586
0x7ac56c output_in_order
/home/rearnsha/gnusrc/gcc-cross/trunk/gcc/cgraphunit.c:2443
0x7ac56c symbol_table::compile()
/home/rearnsha/gnusrc/gcc-cross/trunk/gcc/cgraphunit.c:2683
0x7aef96 symbol_table::compile()
/home/rearnsha/gnusrc/gcc-cross/trunk/gcc/cgraphunit.c:2865
0x7aef96 symbol_table::finalize_compilation_unit()
/home/rearnsha/gnusrc/gcc-cross/trunk/gcc/cgraphunit.c:2862
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/87214] [9 Regression] r263772 miscompiled 520.omnetpp_r in SPEC CPU 2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87214 --- Comment #11 from Martin Liška --- Created attachment 45520 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45520&action=edit optimized dump with -mprefer-vector-width=128
[Bug target/87064] [9 regression] libgomp.oacc-fortran/reduction-3.f90 fails starting with r263751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064 --- Comment #26 from Bill Schmidt --- I believe it's also incorrect (the assumption on the value being in element 3 is a big-endian statement) but latent because this is really hard to match. I'll take an internal note to clean this up. I will also look at backporting these fixes to earlier releases to avoid future rediscovery.
[Bug tree-optimization/87214] [9 Regression] r263772 miscompiled 520.omnetpp_r in SPEC CPU 2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87214
--- Comment #13 from Martin Liška ---
The 2 problematic functions looks like:
void cComponent::reallocParamv(int size)
{
((void)0);
if (size!=(short)size)
throw cRuntimeError(this, "reallocParamv(%d): at most %d parameters
allowed", size, 0x7fff);
cPar *newparamv = new cPar[size];
__builtin_printf ("realloc called with new size: paramvsize: %d\n", numparams);
for (int i=0; igetName());
if (parametersFinalized())
throw cRuntimeError(this, "cannot add parameters at runtime");
if (findPar(value->getName())>=0)
throw cRuntimeError(this, "cannot add parameter `%s': already exists",
value->getName());
if (numparams==paramvsize)
reallocParamv(paramvsize+1);
paramv[numparams++].init(this, value);
}
where the vectorized version prints:
Preparing for running configuration General, run #0...
Scenario: $repetition=0
Assigned runID=speccpu-runid
Setting up network `largeNet'...
addPar: paramvsize: 0, name: n
findPar: n
realloc called with new size: paramvsize: 0
realloc done
findPar: n
addPar: paramvsize: 1, name: bbs
findPar: bbs
realloc called with new size: paramvsize: 1
0:n
0:n
realloc done
findPar: bbs
addPar: paramvsize: 2, name: bbm
findPar: bbm
realloc called with new size: paramvsize: 2
0:n
1:bbs
0:n
1:bbs
realloc done
findPar: bbm
addPar: paramvsize: 3, name: bbl
findPar: bbl
realloc called with new size: paramvsize: 3
0:n
1:bbs
2:bbm
0:n
1:bbs
2:bbm
realloc done
findPar: bbl
addPar: paramvsize: 4, name: as
findPar: as
realloc called with new size: paramvsize: 4
0:n
1:bbs
2:bbm
3:bbl
0:n
1:bbs
2:bbm
3:bbl
realloc done
findPar: as
addPar: paramvsize: 5, name: am
findPar: am
realloc called with new size: paramvsize: 5
0:n
1:bbs
2:bbm
3:bbl
4:as
0:n
1:bbs
2:bbm
3:bbl
4:as
realloc done
findPar: am
addPar: paramvsize: 6, name: al
findPar: al
realloc called with new size: paramvsize: 6
0:n
1:bbs
2:bbm
3:bbl
4:as
5:am
0:n
1:bbs
2:bbm
3:largeNet
4:as
5:am
realloc done
findPar: al
addPar: paramvsize: 7, name: bs
findPar: bs
realloc called with new size: paramvsize: 7
0:n
1:bbs
2:bbm
3:largeNet
4:as
5:am
6:al
0:n
1:bbs
2:bbm
Segmentation fault (core dumped)
As seen the moveto is wrong for paramvsize == 6 (5 old elements), where element
#3 should be 'bbl' after copying, but is 'largeNet'. Then we reach a segfault
due to it.
[Bug tree-optimization/87214] [9 Regression] r263772 miscompiled 520.omnetpp_r in SPEC CPU 2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87214
--- Comment #14 from Martin Liška ---
and moveto does:
void cPar::moveto(cPar& other)
{
other.ownercomponent = ownercomponent;
other.p = p;
p =
# 62 "simulator/cpar.cc" 3 4
__null
# 62 "simulator/cpar.cc"
;
}
