https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82102
Markus Trippelsdorf changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82064
--- Comment #4 from Paul Thomas ---
(In reply to janus from comment #3)
> It appears that the regression has been introduced by r241450, which was the
> fix for PR 69834. Reverting it, in particular the changes to
> resolve_select_type, makes the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80545
--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to Martin Sebor from comment #3)
> Patch posted for review:
> https://gcc.gnu.org/ml/gcc-patches/2017-04/msg01544.html
It seems this patch has been committed as part of r247401 (but unfor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82004
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82089
--- Comment #4 from Tom de Vries ---
For gcn at -O0, I ran into the same problem.
As it turns out, the fixed clause is not triggered for -O0, because the clause
is guarded with:
...
if (GET_MODE_SIZE (target_mode) > GET_MODE_SIZE (result_mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82100
--- Comment #3 from Richard Biener ---
The FEs don't do static analysis that could detect this and it's incredibly
hard to do this during optimization given we'd have to track all instances of
code
(think of inlining, jump threading duplicating b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82101
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82102
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82032
--- Comment #1 from Martin Liška ---
Author: marxin
Date: Tue Sep 5 08:12:27 2017
New Revision: 251690
URL: https://gcc.gnu.org/viewcvs?rev=251690&root=gcc&view=rev
Log:
Learn CFG cleanup to transform single case switches to gcond.
2017-09-05
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82060
Bug 82060 depends on bug 82102, which changed state.
Bug 82102 Summary: [8 Regression] ICE: Segmentation fault in
/home/arnd/git/gcc/gcc/tree-ssa-pre.c:4863
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82102
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82102
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82102
--- Comment #5 from Richard Biener ---
Author: rguenth
Date: Tue Sep 5 08:15:21 2017
New Revision: 251692
URL: https://gcc.gnu.org/viewcvs?rev=251692&root=gcc&view=rev
Log:
2017-09-05 Richard Biener
PR tree-optimization/82102
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82032
Martin Liška changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64910
Rainer Orth changed:
What|Removed |Added
CC||ro at gcc dot gnu.org
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82004
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81913
amker at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62235
--- Comment #14 from Eric Botcazou ---
Author: ebotcazou
Date: Tue Sep 5 09:47:21 2017
New Revision: 251706
URL: https://gcc.gnu.org/viewcvs?rev=251706&root=gcc&view=rev
Log:
PR ada/62235
* gcc-interface/decl.c (gnat_to_gnu_enti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62235
--- Comment #15 from Eric Botcazou ---
Author: ebotcazou
Date: Tue Sep 5 09:49:34 2017
New Revision: 251707
URL: https://gcc.gnu.org/viewcvs?rev=251707&root=gcc&view=rev
Log:
PR ada/62235
* gcc-interface/decl.c (gnat_to_gnu_enti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62235
Eric Botcazou changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81787
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82004
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82104
Bug ID: 82104
Summary: __stack_chk_fail should not use lazy binding on ELF
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81787
--- Comment #4 from Jonathan Wakely ---
(In reply to Manuel López-Ibáñez from comment #2)
> My personal opinion is that we should instead have -Wpermissive, which
> defaults to -Werror=permissive and works like any other -W* option should
> (and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81787
Eric Gallager changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82004
--- Comment #9 from rguenther at suse dot de ---
On Tue, 5 Sep 2017, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82004
>
> Jakub Jelinek changed:
>
>What|Removed |Added
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67559
Eric Gallager changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
Eric Gallager changed:
What|Removed |Added
CC||bisqwit at iki dot fi
--- Comment #15 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79542
--- Comment #11 from pmderodat at gcc dot gnu.org ---
Author: pmderodat
Date: Tue Sep 5 11:04:41 2017
New Revision: 251709
URL: https://gcc.gnu.org/viewcvs?rev=251709&root=gcc&view=rev
Log:
[PR79542][Ada] Fix ICE in dwarf2out.c with nested func.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79542
Pierre-Marie de Rodat changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82043
--- Comment #5 from martin ---
I recompiled gcc 7.2.0 with your applied patch:
I did:
cd gcc-7.2.0/
patch gcc/go/gofrontend/types.cc < ../f9bad13.diff
cd ..
cd gcc-7.2.0-go/
../gcc-7.2.0/configure CC=/opt/gcc-7.1/bin/gcc CXX=/opt/gcc-7.1/bin/g+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82043
--- Comment #6 from martin ---
Created attachment 42122
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42122&action=edit
recompiled-gcc7.2-with-patch
../../../gcc-7.2.0/libgo/go/runtime/mheap.go:867:7: error: type mismatch
between switch v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82105
Bug ID: 82105
Summary: unexpected padding in a struct
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #17 from Jonathan Wakely ---
This adds -Wnon-pod-varargs, enabled by -Wconditionally-supported, allowing
e.g.
-Wconditionally-supported -Werror=non-pod-varargs
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 3435fe90cca..b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82105
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81768
Jakub Jelinek changed:
What|Removed |Added
Keywords|ice-on-invalid-code |ice-on-valid-code
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82105
--- Comment #2 from Dudu ---
I don't think this is how bitfields works.
In the following structs there are no padding between x an y
typedef struct {
unsigned int x:1;
unsigned int y:1;
unsigned short z;
} XXX;
nor in th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81768
--- Comment #4 from Jakub Jelinek ---
Created attachment 42123
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42123&action=edit
gcc8-pr81768.patch
Untested fix for the simd expansion bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82078
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82105
--- Comment #3 from Andreas Schwab ---
Bit fields are not allocated across unit boundaries.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82105
--- Comment #4 from Dudu ---
Sorry, Andreas
I don't understand your comment - can you please explain?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82084
--- Comment #9 from Richard Biener ---
Author: rguenth
Date: Tue Sep 5 12:58:00 2017
New Revision: 251711
URL: https://gcc.gnu.org/viewcvs?rev=251711&root=gcc&view=rev
Log:
2017-09-05 Richard Biener
PR tree-optimization/82084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80865
Christian Cornelssen changed:
What|Removed |Added
CC||pkg at 1tein dot de
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80865
--- Comment #3 from Christian Cornelssen ---
Created attachment 42124
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42124&action=edit
Darwin/PPC patches mentioned in
https://gcc.gnu.org/ml/gcc-testresults/2017-01/msg02971.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65146
Peter Cordes changed:
What|Removed |Added
CC||peter at cordes dot ca
--- Comment #4 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81768
--- Comment #5 from Jakub Jelinek ---
Created attachment 42126
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42126&action=edit
gcc8-pr81768-2.patch
And an untested fix for the other reported bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71660
--- Comment #7 from Peter Cordes ---
C++11 std::atomic<> is correct, and the change was necessary.
8B alignment is required for 8B objects to be efficiently lock-free (using SSE
load / store for .load() and .store(), see
https://stackoverflow.co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81942
--- Comment #16 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Tue Sep 5 13:33:44 2017
New Revision: 251714
URL: https://gcc.gnu.org/viewcvs?rev=251714&root=gcc&view=rev
Log:
/cp
2017-09-05 Paolo Carlini
PR c++/81942
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81942
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65146
Uroš Bizjak changed:
What|Removed |Added
Keywords||ABI
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68159
--- Comment #15 from Carlos Alberto Lopez Perez ---
(In reply to H.J. Lu from comment #11)
> *** Bug 68383 has been marked as a duplicate of this bug. ***
Bug 68383 was fixed by r245978
So, this one is also fixed right ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65146
--- Comment #6 from Peter Cordes ---
My test-case on godbolt: https://godbolt.org/g/MmLycw. gcc8 snapshot still
only has 4B alignment
Fun fact: clang4.0 -m32 inlines lock cmpxchg8b for 8-byte atomic load/store.
This is ironic, because it *does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80865
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
bogcujd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71660
--- Comment #8 from Thiago Macieira ---
(In reply to Peter Cordes from comment #7)
> 8B alignment is required for 8B objects to be efficiently lock-free (using
> SSE load / store for .load() and .store(), see
> https://stackoverflow.com/questions
ble-gdb
--disable-libssp --with-newlib --with-arch=rv32ima --with-abi=ilp32
--prefix=/home/asb/work/2017_09_05_gcc_build/combined/build/built
Thread model: single
gcc version 8.0.0 20170905 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-march=rv32ifd' '-mabi=i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65146
--- Comment #7 from H.J. Lu ---
We need to first decide what we want out of i386 atomic.
Please send a post to
https://groups.google.com/forum/#!forum/ia32-abi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82043
--- Comment #7 from Ian Lance Taylor ---
Sorry, I'm not sure what is causing that error.
Why don't you just compile GCC trunk?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82105
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #19 from Jonathan Wakely ---
Whether Clang warns or not depends on the -std mode active, as that decides the
definition of a POD it uses. GCC always uses the C++11 rule, which I quoted in
comment 9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71660
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
Depends on|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82080
--- Comment #1 from Eric Gallager ---
Created attachment 42128
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42128&action=edit
error messages printed when trying to compile
I can't reproduce this bug on i386-apple-darwin9.8.0; with -m32 I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82075
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82072
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82072
--- Comment #16 from Marek Polacek ---
Author: mpolacek
Date: Tue Sep 5 15:55:04 2017
New Revision: 251717
URL: https://gcc.gnu.org/viewcvs?rev=251717&root=gcc&view=rev
Log:
PR sanitizer/82072
* convert.c (convert_to_integer_1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82072
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82073
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82107
Bug ID: 82107
Summary: O2 optimisation on amd64 leads to error
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82107
--- Comment #1 from loquens at yandex dot ru ---
Additional research found, that error produced by
-O1 and -finline-small-functions -fipa-icf -foptimize-sibling-calls.
All three flags must be present to get an error.
If you exclude -foptimize-s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82106
--- Comment #1 from Palmer Dabbelt ---
Ugh. I'd really like to call this a bug and fix it, but since it'll
technically break the ABI it'll require some more thought.
Does "-mstrict-align" change the behavior? That would be a good argument to
f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82106
--- Comment #2 from Alex Bradbury ---
Same problem with `-mstrict-align`, which as you say makes this worse.
I'm actually not sure if this is an ABI-visible issue. The vararg save area and
it's location is basically required by the ABI due to th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82073
--- Comment #2 from Vsevolod Livinskiy ---
(In reply to Eric Gallager from comment #1)
> Could you post the output of g++ -v so we have version and target info
> please?
Revision is 251589
>$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81787
--- Comment #6 from Manuel López-Ibáñez ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Manuel López-Ibáñez from comment #2)
> > My personal opinion is that we should instead have -Wpermissive, which
> > defaults to -Werror=permi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82108
Bug ID: 82108
Summary: [7.2 Regression] Wrong vectorized code generated for
x86_64
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59501
--- Comment #7 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Tue Sep 5 16:39:24 2017
New Revision: 251718
URL: https://gcc.gnu.org/viewcvs?rev=251718&root=gcc&view=rev
Log:
i386: Avoid stack realignment if possible
ix86_finalize_stack_fram
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81769
--- Comment #1 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Tue Sep 5 16:39:24 2017
New Revision: 251718
URL: https://gcc.gnu.org/viewcvs?rev=251718&root=gcc&view=rev
Log:
i386: Avoid stack realignment if possible
ix86_finalize_stack_fram
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81624
--- Comment #3 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Tue Sep 5 16:39:24 2017
New Revision: 251718
URL: https://gcc.gnu.org/viewcvs?rev=251718&root=gcc&view=rev
Log:
i386: Avoid stack realignment if possible
ix86_finalize_stack_fram
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80925
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71660
--- Comment #10 from Thiago Macieira ---
Actually, PR 65146 points out that the problem is not efficiency but
correctness. An under-aligned type could cross a cacheline boundary and thus
fail to be atomic in the first place.
Therefore, it is cor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81787
--- Comment #7 from Jonathan Wakely ---
Accepting invalid C++ changes the language. It's not a diagnostic option, it's
closer to -std in meaning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82105
--- Comment #6 from Dudu ---
Thanks for the replies, but I do not look to workaround this issue.
I simply wonder why gcc behaves as it does on this case.
This behavior breaks my understanding of padding.
This behavior seems wrong.
This behavior l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82080
James Almer changed:
What|Removed |Added
Attachment #42105|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82108
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82063
--- Comment #5 from Jim Wilson ---
(In reply to Martin Sebor from comment #3)
> Jim, since you've spent some time on this already and understand the
> problems, please feel to propose a patch. If you don't get to it I'll see
> if I can find the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82106
--- Comment #3 from Andrew Waterman ---
I believe Alex is correct, in that this is an implementation artifact that
can be fixed without breaking the ABI.
On Tue, Sep 5, 2017 at 9:26 AM asb at lowrisc dot org <
gcc-bugzi...@gcc.gnu.org> wrote:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82107
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82064
--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #4)
> (In reply to janus from comment #3)
> > It appears that the regression has been introduced by r241450, which was the
> > fix for PR 69834. Reverting it, i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78015
--- Comment #4 from Jakub Jelinek ---
No, but I'm not familiar enough with the C++ EH libsupc++ stuff to write it
myself. Jason, do you think you could try that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82106
--- Comment #4 from Palmer Dabbelt ---
Ya, sorry, I misread the assembly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78015
--- Comment #5 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #0)
> fails with std::terminate (), while works with -DWORKAROUND.
It's the other way around, right? Was the testcase meant to use #ifndef?
I can take a look at wra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78015
--- Comment #6 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to Jakub Jelinek from comment #0)
> > fails with std::terminate (), while works with -DWORKAROUND.
>
> It's the other way around, right? Was the test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82109
Bug ID: 82109
Summary: False positive when using pthread_cleanup_push() and
pthread_cancel()
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81833
--- Comment #3 from Bill Schmidt ---
Author: wschmidt
Date: Tue Sep 5 19:41:55 2017
New Revision: 251723
URL: https://gcc.gnu.org/viewcvs?rev=251723&root=gcc&view=rev
Log:
[gcc]
2017-09-05 Bill Schmidt
PR target/81833
* con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82053
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82095
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |8.0
Summary|ICE in tree_nop_c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81768
--- Comment #6 from Jakub Jelinek ---
Author: jakub
Date: Tue Sep 5 21:31:39 2017
New Revision: 251741
URL: https://gcc.gnu.org/viewcvs?rev=251741&root=gcc&view=rev
Log:
PR middle-end/81768
* omp-expand.c (expand_omp_simd): Forc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71660
--- Comment #11 from Peter Cordes ---
(In reply to Thiago Macieira from comment #10)
> Actually, PR 65146 points out that the problem is not efficiency but
> correctness. An under-aligned type could cross a cacheline boundary and thus
> fail to b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81768
--- Comment #7 from Jakub Jelinek ---
Author: jakub
Date: Tue Sep 5 21:32:35 2017
New Revision: 251742
URL: https://gcc.gnu.org/viewcvs?rev=251742&root=gcc&view=rev
Log:
PR middle-end/81768
* omp-low.c (lower_omp_for): Recompute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82048
--- Comment #5 from Aaro Koskinen ---
> Is there any workaround other than downgrading to glibc 2.24 on SPARC?
If you always re-install the 64-bit glibc build after 32-bit one, that should
restore the correct version of long-double.h.
1 - 100 of 118 matches
Mail list logo
