https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81449
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81449
--- Comment #3 from Ian Lance Taylor ---
Thanks for reporting it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70589
Michael Meissner changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81450
Bug ID: 81450
Summary: Typedef with assume aligned builtin yields
segmentation fault in nested loop
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45896
--- Comment #8 from Jonathan Wakely ---
(In reply to xyzdragon from comment #7)
> Had this bug when trying "%m" formatter on input "7" input. Saw the comment
> from 7 years ago "Can fix pretty quickly." and let out a desperate laugh. Is
> C++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81445
--- Comment #6 from Marc Glisse ---
(In reply to Wilco from comment #5)
> Also it doesn't support these simple cases:
>
> void vla2(int x)
> {
> if (x == 10)
> {
> int arr[x];
> t (arr);
> }
> }
Again, try something smaller. When
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81449
--- Comment #1 from martin ---
Created attachment 41761
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41761=edit
runtime.inc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79856
Roland Illig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81445
--- Comment #5 from Wilco ---
(In reply to Marc Glisse from comment #4)
> (In reply to Wilco from comment #2)
> > I don't see it happen for the simplest case in current trunk:
>
> 400 bytes is too large, try again with something smaller. (I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81162
Bill Schmidt changed:
What|Removed |Added
Known to work||8.0
--- Comment #9 from Bill Schmidt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81162
--- Comment #8 from Bill Schmidt ---
Author: wschmidt
Date: Fri Jul 14 18:06:45 2017
New Revision: 250212
URL: https://gcc.gnu.org/viewcvs?rev=250212=gcc=rev
Log:
[gcc]
2016-07-14 Bill Schmidt
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81449
Bug ID: 81449
Summary: runtime.inc:782:28: error: field ‘__sem_lock’ has
incomplete type
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81421
martin changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71504
Tom Westerhout changed:
What|Removed |Added
CC||kot.tom97 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81300
Uroš Bizjak changed:
What|Removed |Added
Target|x86-*-* |x86
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81375
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81448
--- Comment #4 from Bernd Edlinger ---
(In reply to Marek Polacek from comment #3)
> Guess we'll need the PR81364 fix for that.
Yes, although it would be good to require
a "{" only if cprefix##_ecb_encrypt(...) actually expands
to multiple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81375
--- Comment #5 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Jul 14 17:19:30 2017
New Revision: 250211
URL: https://gcc.gnu.org/viewcvs?rev=250211=gcc=rev
Log:
Backport from mainline
2017-07-10 Uros Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81300
--- Comment #5 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Jul 14 17:19:30 2017
New Revision: 250211
URL: https://gcc.gnu.org/viewcvs?rev=250211=gcc=rev
Log:
Backport from mainline
2017-07-10 Uros Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81346
--- Comment #10 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #9)
> (In reply to Marc Glisse from comment #8)
> > I think always using an unsigned type for the range check would be simpler.
> > If we try to check that x>=INT_MIN+2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81448
--- Comment #3 from Marek Polacek ---
Guess we'll need the PR81364 fix for that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81445
--- Comment #4 from Marc Glisse ---
(In reply to Wilco from comment #2)
> I don't see it happen for the simplest case in current trunk:
400 bytes is too large, try again with something smaller. (I'm with you if you
want to increase the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68972
--- Comment #13 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Fri Jul 14 16:58:00 2017
New Revision: 250210
URL: https://gcc.gnu.org/viewcvs?rev=250210=gcc=rev
Log:
gcc/ChangeLog:
2017-07-14 Kelvin Nilsen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
--- Comment #6 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Fri Jul 14 16:58:00 2017
New Revision: 250210
URL: https://gcc.gnu.org/viewcvs?rev=250210=gcc=rev
Log:
gcc/ChangeLog:
2017-07-14 Kelvin Nilsen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80101
--- Comment #3 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Fri Jul 14 16:58:00 2017
New Revision: 250210
URL: https://gcc.gnu.org/viewcvs?rev=250210=gcc=rev
Log:
gcc/ChangeLog:
2017-07-14 Kelvin Nilsen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80103
--- Comment #5 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Fri Jul 14 16:58:00 2017
New Revision: 250210
URL: https://gcc.gnu.org/viewcvs?rev=250210=gcc=rev
Log:
gcc/ChangeLog:
2017-07-14 Kelvin Nilsen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81346
--- Comment #9 from Jakub Jelinek ---
(In reply to Marc Glisse from comment #8)
> I think always using an unsigned type for the range check would be simpler.
> If we try to check that x>=INT_MIN+2 && x<=INT_MAX-2 with -fwrapv, int is
> still not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81448
--- Comment #2 from Bernd Edlinger ---
Not really:
diff --git a/crypto/evp/evp_locl.h b/crypto/evp/evp_locl.h
index 2bb709a..cb44ed8 100644
--- a/crypto/evp/evp_locl.h
+++ b/crypto/evp/evp_locl.h
@@ -71,8 +71,9 @@
#define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80935
Andrew Wong changed:
What|Removed |Added
CC||andrew.kw.w at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81346
--- Comment #8 from Marc Glisse ---
I think always using an unsigned type for the range check would be simpler. If
we try to check that x>=INT_MIN+2 && x<=INT_MAX-2 with -fwrapv, int is still
not a suitable type in which to do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81421
--- Comment #17 from Ian Lance Taylor ---
Thanks. I have no recommendation. I can not explain why your version of grep
behaves differently than mine, and, since nobody else has reported this bug,
apparently differently than everyone else's.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81421
--- Comment #16 from martin ---
For clarification the duplicate of "/go/runtime/mksizeclasses.go > FILE" was a
copy paste mistake.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81445
--- Comment #3 from Wilco ---
There is also something buggy with the way alloca aligns, it always allocates
16 bytes too much...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81421
--- Comment #15 from martin ---
You are right!
I did:
sed '/^package /q' < /media/gcc-7.1.0/libgo/go/runtime/mksizeclasses.go > FILE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81445
--- Comment #2 from Wilco ---
(In reply to Marc Glisse from comment #1)
> Note that we already do it for VLA (aka BUILT_IN_ALLOCA_WITH_ALIGN) in CCP.
I don't see it happen for the simplest case in current trunk:
void t(int *);
void vla(void)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81448
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81448
Bug ID: 81448
Summary: False positive -Werror=multistatement-macros in
openssl
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81421
--- Comment #14 from Ian Lance Taylor ---
OK, so the sed command works. Run the sed command redirecting standard output
to a file, then see what this prints:
grep '^// +build ' FILE
It sounds like that will print nothing. The only way I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81446
--- Comment #1 from John Paul Adrian Glaubitz ---
I can confirm that the previously suggested patch fixes the issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81445
--- Comment #1 from Marc Glisse ---
Note that we already do it for VLA (aka BUILT_IN_ALLOCA_WITH_ALIGN) in CCP.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81447
Bug ID: 81447
Summary: gfortran fails to recognize the exact dynamic type of
a polymorphic entity that was allocated in a external
procedure
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81421
--- Comment #13 from martin ---
Thanks for the fast reply.
It prints:
nas-02-90-38:/media/gcc-7.1.0/libgo# sed '/^package /q' <
/media/gcc-7.1.0/libgo/go/runtime/mksizeclasses.go
// Copyright 2016 The Go Authors. All rights reserved.
// Use of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81421
--- Comment #12 from Ian Lance Taylor ---
Sorry, I meant: what does this print?
sed '/^package /q' < SRCDIR/libgo/go/runtime/mksizeclasses.go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70140
Martin Sebor changed:
What|Removed |Added
Keywords||missed-optimization
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81421
--- Comment #11 from martin ---
nas-02-90-38:/media/gcc-7.1.0/libgo# sed
Usage: sed [OPTION]... {script-only-if-no-other-script} [input-file]...
-n, --quiet, --silent
suppress automatic printing of pattern space
-e script,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81421
--- Comment #10 from Ian Lance Taylor ---
As far as I know your sed and grep are sufficiently up to date. What does the
sed command by itself print on your system?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81147
--- Comment #5 from Georg-Johann Lay ---
What you mean by "NRVO" and "RVO" ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81446
Bug ID: 81446
Summary: Building Ada on Linux m68k fails due to missing
No_Elaboration_Code_All
Product: gcc
Version: 7.1.0
URL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81312
--- Comment #6 from H.J. Lu ---
(In reply to Jan Hubicka from comment #5)
> What are the code size/performance tradeoffs in 32bit/64bit mode with Intel
> machines?
Pavel, should we investigate it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45896
xyzdragon at fastmail dot fm changed:
What|Removed |Added
CC||xyzdragon at fastmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81421
--- Comment #9 from martin ---
The OS is based on debian with some custom modification from Netgear.
I thought I "upgraded" all neccessary libraries for gcc 7.1.0.
ldconfig -V
ldconfig (GNU libc) 2.3.2
sed --version
GNU sed version 4.1.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81312
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59521
--- Comment #12 from Ulrich Drepper ---
On Fri, Jul 14, 2017 at 2:17 PM, marxin at gcc dot gnu.org
wrote:
> Maybe I miss something, but I would expect to sort all branches in
> emit_case_decision_tree as either
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81445
Bug ID: 81445
Summary: Dynamic stack allocation not optimized into static
allocation
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81421
--- Comment #8 from Ian Lance Taylor ---
On my system I see this:
> sed '/^package /q' < ~/gcc/gcc-7-branch/libgo/go/runtime/mksizeclasses.go |
> grep '^// +build ' | cat
// +build ignore
That is, the command displays `// +build ignore`. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70140
--- Comment #4 from H.J. Lu ---
(In reply to Wilco from comment #3)
> Yes. Ignoring GLIBC internals, mempcpy is used quite infrequently. As a
> result not many targets have added highly optimized implementations. The
> targets that do have the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70140
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81346
Jakub Jelinek changed:
What|Removed |Added
Attachment #41707|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81444
--- Comment #1 from Georg-Johann Lay ---
Created attachment 41759
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41759=edit
Proposed patch.
PR middle-end/81444
* expmed.c (init_expmed_one_conv): Don't clobber all->reg's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71112
Ramana Radhakrishnan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81444
Bug ID: 81444
Summary: expmed.c:init_expmed_one_mode uses wrong mode for
widening cost computations
Product: gcc
Version: 7.1.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59521
--- Comment #11 from Martin Liška ---
(In reply to Yuri Gribov from comment #10)
> (In reply to Martin Liška from comment #9)
> > The patch works for me for the described case, but does not for PGO, which
> > should do the same based on real
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59521
--- Comment #10 from Yuri Gribov ---
(In reply to Martin Liška from comment #9)
> The patch works for me for the described case, but does not for PGO, which
> should do the same based on real numbers:
Problem here is that we optimize only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80573
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81030
Tom de Vries changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70140
--- Comment #2 from Martin Liška ---
I've just taken look at that and please confirm that I understand that
correctly:
1) we want to ideally a same function for expansion of memcpy and mempcpy,
where for later one we'll append calculation of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81443
Bug ID: 81443
Summary: gcc-7.1.0/MIPS N32: build/genrecog.o: virtual memory
exhausted: Cannot allocate memory
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81442
--- Comment #2 from Tom de Vries ---
(In reply to Tom de Vries from comment #1)
> I'm currently testing if that also makes the test-case pass.
It does.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81442
--- Comment #1 from Tom de Vries ---
Created attachment 41758
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41758=edit
Tentative patch
I'm not sure how this is supposed to be fixed.
But this is a point fix that at least allows lto1 to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81066
--- Comment #14 from Jakub Jelinek ---
Author: jakub
Date: Fri Jul 14 09:10:45 2017
New Revision: 250200
URL: https://gcc.gnu.org/viewcvs?rev=250200=gcc=rev
Log:
PR sanitizer/81066
* sanitizer_common/sanitizer_linux.h:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81442
Bug ID: 81442
Summary: error: verify_flow_info: REG_BR_PROB is set but cfg
probability is not during RTL pass: outof_cfglayout
Product: gcc
Version: 8.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564
--- Comment #23 from Jakub Jelinek ---
The bug is fixed, you must be running into a different issue, either in the
source you're compiling, or in the compiler. So, please open a new bugreport
instead of commenting on a different one, and supply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81416
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79765
Martin Liška changed:
What|Removed |Added
Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81416
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79902
Martin Liška changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81416
--- Comment #4 from bz0815 at tirol dot com ---
(In reply to Andrew Pinski from comment #3)
> > DOUBLE PRECISION,DIMENSION(n) :: b
>
> This array is on the stack.
So
DOUBLE PRECISION,DIMENSION(n) :: b
is put on the stack if it is passed as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81421
--- Comment #7 from martin ---
/media/gcc-7.1.0 is my source dir
nas-02-90-38:/media/gcc-7.1.0# libgo/match.sh --goarch=sparc --goos=linux
--srcdir=/media/gcc-7.1.0/libgo/go/runtime --extrafiles="runtime_sysinfo.go
sigtab.go" --tag=libffi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79659
Martin Liška changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79856
Martin Liška changed:
What|Removed |Added
Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81441
Bug ID: 81441
Summary: slowdown due to -fpeel-loops and -ftracer added by
-fprofile-use
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81396
--- Comment #6 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #5)
> Or both this bswap change and the match.pd addition.
Doing both sounds good to me :-)
82 matches
Mail list logo