https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87317
--- Comment #4 from Marc Glisse ---
> (match_operand:DI 1 "nonimmediate_operand" "m,*m,m")
Does it have to come from memory, can't it also come from a (sub)register?
int f(__m64 x){
__m128i y = _mm_movpi64_epi64(x); // or harder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71157
Eric Gallager changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87319
--- Comment #2 from Marc Glisse ---
*** Bug 87323 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87323
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87317
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87317
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70082
--- Comment #7 from Carlos O'Donell ---
(In reply to Martin Sebor from comment #6)
> Carlos, do you still feel diagnosing some of the [mis]uses would be helpful,
> e.g., by a warning? (I ask because I've been doing some work in this area
> --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87318
--- Comment #3 from Jerry DeLisle ---
Created attachment 44700
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44700=edit
Revised dtio_1.f90
Will this attached version suffice? When we wrote the test case we were not
going for valid code,
Thanks for the reviews. I have incorporated all but one (See below; its the
change in the warning's
brief summary in common.opt) in the patch.
In this patch,
1. -Wmissing-profile is a warning by default and is ON by default with
-fprofile-use
2. Attached pr86957-missing-profile-diagnostic-2
Committed.
Gerald
2018-09-16 Gerald Pfeifer
* doc/service.texi (Service): Switch the fsf.org link to https.
Index: doc/service.texi
===
--- doc/service.texi(revision 264342)
+++ doc/service.texi(working copy)
@@
We had this left on the main page. I makes a slight visual difference,
but not signficant, and I plan on replacing the formatting via a table
mid term.
Applied.
Gerald
Index: style.mhtml
===
RCS file:
Similar to what I did with gcc-3.3/gcj-status.html a few days ago.
Committed.
Gerald
Index: gcc-3.1/gcj-status.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.1/gcj-status.html,v
retrieving revision 1.6
diff -u -r1.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87323
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 9.0.0 20180915 (experimental) [trunk revision 264342] (GCC)
$ g++-trunk abc.C
abc.C:9:18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65158
--- Comment #5 from Manuel López-Ibáñez ---
(In reply to Martin Sebor from comment #4)
> What follows the percent sign must one of the C or POSIX conversion
> specifiers (after any optional flags etc.) and those are all single byte
> characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87315
--- Comment #5 from Manuel López-Ibáñez ---
(In reply to Martin Sebor from comment #4)
> To be clear: besides the missing warning this is also about the kind of code
> GCC emits for the uninitialized read -- a missed-optimization for lack of a
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87323
Bug ID: 87323
Summary: More complicated assembly for sode with custom copy
constructor
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86484
--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to janus from comment #4)
> The following draft patch fixes both this one and PR 84543:
... and regtests cleanly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86551
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
On Sat, Sep 15, 2018 at 03:28:17PM -0500, Bill Schmidt wrote:
> Jinsong Ji reported that these header files are using the non-ABI type
> __int128_t rather than __int128. This patch from Jinsong corrects this.
> Bootstrapped and tested on powerpc64le-linux-gnu with no regressions,
> committed as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86551
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-invalid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86484
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Hi,
Jinsong Ji reported that these header files are using the non-ABI type
__int128_t rather than __int128. This patch from Jinsong corrects this.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions,
committed as obvious.
Thanks,
Bill
2018-09-15 Jinsong Ji
Bill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87322
Bug ID: 87322
Summary: [GCC 8.1+] GCC fails to parse captured lambda of 2nd
inner lambda if the captured lambda has "," (having 2
arguments)
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86484
janus at gcc dot gnu.org changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86484
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87209
--- Comment #3 from Martin Sebor ---
(As suggested in bug 87315) besides issuing a warning it would be safer to do
what Clang does in cases like this and either replace the code with a trap, or
simply eliminate the access (and the malloc call)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87315
--- Comment #4 from Martin Sebor ---
To be clear: besides the missing warning this is also about the kind of code
GCC emits for the uninitialized read -- a missed-optimization for lack of a
better term/keyword. It would be safer to do what
> Honza,
>
> At the Cauldron meeting last week I mentioned that I wasn't able to compile
> our "small" weather forecasting program with LTO.
>
> In the mean time I have read some bug reports with "multiple prevailing ..."
> errors, which made me try linking with the 'gold' linker - that worked.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87320
Bug ID: 87320
Summary: Last iteration of vectorized loop not executed when
peeling for gaps
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87318
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87318
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87316
--- Comment #6 from David ---
clang 6 does the compilation in under 1 second on the same container.
$ clang-6.0 -v
clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87140
Emiliano Silvestri changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87319
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65158
--- Comment #4 from Martin Sebor ---
(In reply to Manuel López-Ibáñez from comment #3)
> void foo(void) {
> __builtin_printf("%ñ%中");
> __builtin_printf ("%\x1B$B"); /* Taken from PR33748 */
> }
>
> : In function 'void foo()':
> :2:22:
On Sat, Sep 15, 2018 at 7:12 AM, graham stott via gcc-patches
wrote:
> Hi
> Fails due to undefind symbols runtime.*
> O2 works
I tried my best guess at recreating the problem, and everything worked fine.
Please tell us exactly what you did and exactly what happened.
Thanks.
Ian
Hi
Fails due to undefind symbols runtime.*
O2 works
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87319
Bug ID: 87319
Summary: When vector is wrapped, expression is not optimized.
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #20 from Marc Glisse ---
(In reply to Vincent Lefèvre from comment #18)
> OK, but then, this means that the first sentence of the
> -Wmaybe-uninitialized documentation is incorrect. That's probably the "there
> exists" that is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87299
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords|diagnostic |
--- Comment #2 from Manuel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87299
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Hello,
as explained in the PR, the implementation of vector is weirdly
wasteful. Preserving the ABI prevents from changing much for now, but this
small tweak can help the compiler remove quite a bit of dead code.
I think most other direct uses of _M_start are in constructors where the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #19 from Manuel López-Ibáñez ---
(In reply to Vincent Lefèvre from comment #18)
> OK, but then, this means that the first sentence of the
> -Wmaybe-uninitialized documentation is incorrect. That's probably the "there
> exists" that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65158
Manuel López-Ibáñez changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87316
--- Comment #5 from David ---
I've isolated the compilation and the results are still as above -- new
versions of gcc are significantly slower compiling the attached test.i.
Using this command: gcc -std=gnu99 -O0 -c test.i
gcc 7.3.0 (Ubuntu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55060
Manuel López-Ibáñez changed:
What|Removed |Added
Known to work||9.0
--- Comment #6 from Manuel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87209
Manuel López-Ibáñez changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87315
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87310
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87310
--- Comment #4 from Róbert Kohányi ---
Created attachment 44698
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44698=edit
/usr/lib/gcc/x86_64-linux-gnu/5/include/stdbool.h
Here's the on Ubuntu using gcc 5.4.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87310
--- Comment #3 from Róbert Kohányi ---
Created attachment 44697
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44697=edit
/usr/lib/gcc/x86_64-pc-msys/7.3.0/include/stdbool.h
Here's the referenced on Windows using gcc 7.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87315
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86990
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86864
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
for a BARRIER
before and after a JUMP_TABLE_DATA.
2018-09-15 Eric Botcazou
* gcc.c-torture/compile/20180915-1.c: New test.
--
Eric BotcazouIndex: cfgexpand.c
===
--- cfgexpand.c (revision 264202)
+++ cfgexpand.c
): Be prepared for a BARRIER
before and after a JUMP_TABLE_DATA.
Added:
trunk/gcc/testsuite/gcc.c-torture/compile/20180915-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/testsuite/ChangeLog
Hi,
this is an update on my strlen range patch (V7). Again re-based and
retested to current trunk.
I am aware that Martin wants to re-factor the interface of get_range_strlen
and have no objections against, but I'd suggest that to be a follow-up patch.
I might suggest to rename one of the two
On 9/14/18, Martin Sebor wrote:
> As I said above, this happens during the dom walk in the ccp
> pass:
>
> substitute_and_fold_dom_walker walker (CDI_DOMINATORS, this);
> walker.walk (ENTRY_BLOCK_PTR_FOR_FN (cfun));
>
> The warning is issued during the walker.walk() call as
> strncpy is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87318
Bug ID: 87318
Summary: gfortran.dg/dtio_1.f90 is invalid
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87315
--- Comment #1 from Marc Glisse ---
There could be 2 steps:
- replace the read with an undefined value (SSA_NAME with GIMPLE_NOP defining
statement). I vaguely remember someone was not enthusiastic about it, but I
don't remember why.
- fold a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87317
Marc Glisse changed:
What|Removed |Added
Keywords||missed-optimization
Target|
Sorry for doing the same mistake twice. Is this OK, and do
I need to test it again after the first version of this
patch?
2018-09-15 MCC CS
gcc/
PR tree-optimization/87261
* match.pd: Add boolean optimizations,
fix whitespace.
2018-09-15 MCC CS
63 matches
Mail list logo
